Language

Digital Public Infrastructure

Why DPI Must Be Built on Open Standards

Ajay Jadhav 5 min read

We have been building digital identity infrastructure for governments and enterprises for over seven years now. And if there is one thing we keep coming back to, it is this: the moment you let a proprietary platform become the backbone of national infrastructure, you have already lost the plot.

It sounds dramatic, but think about it. When a country decides to build its digital public infrastructure — the rails on which healthcare, education, finance, and governance will run — they are making a decision that will outlast every government, every vendor contract, and quite possibly every technology that exists today.

The Proprietary Trap

A few years ago, we were talking to a government team that had built their entire citizen identity system on a commercial off-the-shelf product. It worked great for the first few years. Then they wanted to add verifiable credential support. The vendor quoted them a six-figure "integration fee" and a timeline of eighteen months. Eighteen months to add something that should have been an API call.

That is the proprietary trap. You do not own your roadmap. The vendor does.

Open standards flip this entirely. When you build on W3C Verifiable Credentials, DID Core, or OpenID4VC, you are not tied to any implementation. You can switch vendors, run multiple implementations in parallel, and — most importantly — your system can interoperate with any other system that speaks the same standards.

What Open Standards Give You

In our work building CREDEBL, we have seen first-hand what happens when you commit to open standards from day one. Three things stand out:

Interoperability without negotiation. We have connected CREDEBL with half a dozen other issuer and verifier implementations without a single bilateral agreement. They all speak W3C VC and DID. That is the whole point.

Auditability. Open standards mean open specifications. Anyone can audit what the system is supposed to do. For national infrastructure, this is non-negotiable.

Ecosystem effects. When India built Aadhaar, they used open standards for the UIDAI ecosystem. Today, thousands of applications integrate with it. That network effect happened because the barriers to entry were low — any developer could read the spec and build.

The False Choice

Vendors will tell you that proprietary systems are "more secure" or "more performant." In our experience, this is almost never true. Open source implementations of the same standards regularly outperform commercial ones because they have more eyes on the code and more diverse deployment scenarios stress-testing them.

Security through obscurity is not security. It is just obscurity.

Where We Landed

Every component we build at AYANWORKS — CREDEBL, Sovio, our credential wallet libraries — is built on open standards first. We contribute back to the specifications, we file issues when we hit edge cases, and we run our implementation through interoperability events like the ones organized by the OpenID Foundation and the W3C CCG.

This is not charity. It is self-interest. Because the stronger the open standards ecosystem gets, the more valuable our contribution becomes, and the better infrastructure our clients end up with.

If you are evaluating technology for national or enterprise digital infrastructure, ask one question: Can I take my data and run it on a different system tomorrow? If the answer is anything but yes, you are building on sand.

A

Ajay Jadhav

CTO, AYANWORKS

Share X LinkedIn

More Articles