DPI Design Principle #2, 3: Interoperability, Federation

The second design principle behind India’s DPI (Digital Public Infrastructure) is interoperability. As any engineer will tell you, systems rarely talk to each other. Every piece gets optimized for itself, and thus is rarely suited to work with anything else. Plus, companies deliberately choose to keep things in proprietary formats so customers cannot easily switch out.

 

When we say Aadhar is the world’s first digital ID system, it doesn’t just mean that the ID was created and stored in digital format. It means a lot more than that, as Rahul Matthan explains in The Third Way. It means that it was designed to be usable in all kinds of digital workflows, an example of which we saw in an earlier blog on the design of UPI by unbundling things first.

 

Another example is Aadhar’s integration with Jeevan Praman, a government pension service. Proof of life can be established remotely by a pensioner, thanks to Aadhar’s interoperability. This is hugely helpful in the rural hinterland saving one a costly and time-consuming trip to the nearest big town or city.

 

Designing for interoperability doesn’t mean you know upfront all possible uses. Rather, you design in a way such that newer applications and uses can be built on/alongside it later, stuff nobody could even imagine when originally created.

 

Another key design principle was to allow it answer only Yes/No questions. Is the individual alive? Is he an adult? While only allowing Yes/No answers can be a constraint for several situations, it also means that the entity asking the query cannot get a billion pieces of data about an individual under the actual need to get one piece of information. Privacy considerations trumped convenience. By design. This was a particularly smart choice because the system was designed to allow private players into the mix (think PhonePe and GPay), many of who cannot/should not be trusted with all our data. This avoids the problem the West has – Google and Facebook know everything.

~~

 

A third design principle of DPI is federation. This means that data should be deliberately scattered and distributed across as many entities as possible, not centralized in a few databases. This design principle was for safety reasons on two fronts: (1) Hackers would get everything if they got into the one centralized database; (2) Governments could misuse the power of having access to all data.

 

Plus, distributed data can help ensure every entity has what it needs, not more. A healthcare entity needs to know of your health records but not your education level. But sometimes, we need to connect these data silos. Isn’t that a drawback of such a federated design? Yes, which is why DEPA (Data Empowerment and Protection Architecture) was created to allow for data flows across these silos. But only with the consent of the individual.

 

DigiYatra is a good example of federation. All the data (one’s photo, travel details etc) is stored on the phone itself. Shortly before travel, that information is shared with the airport. Within 24 hours of departure, all that data is purged from the airport’s systems. This is a perfect example of sharing the data for only the relevant duration, not left to the discretion of the entity who gets it. And the user authorizes the sharing of the data.

 

DPI, as you can see, didn’t just turn out the way it is by happy accident. It was deliberately designed to be that way.