The five technology architecture principles above illustrate how DPI efforts can be architected to be distinct from traditional digitisation efforts: 1) interoperability; 2) minimalist, reusable building blocks; 3) Diverse, inclusive innovation by the ecosystem; 4) a preference for remaining federated and decentralised; and 5) security & privacy by design.

When implemented, these technical principles help DPIs achieve societal outcomes such as inclusion, user choice, innovation, scale of delivery, speed of services, public trust, competition in markets, and others as outlined below.

In a crowded technology innovation landscape and a sometimes polarised geopolitical climate, Digital Public Infrastructure has emerged as an unusual point of convergence across countries. It is now well acknowledged as a powerful strategy to drive inclusive and sustainable economic growth.

Through the DPI Wiki, we've attempted to distil 15 years of practical implementation experience and insight across countries - cutting across some of the key areas that make up what we call the ‘DPI Approach’. It is designed to be a living resource, constantly updated with what is new and what is important.

We’ve tried to simplify it to the absolute minimum of what you need to know to get started in the execution of an inclusive, interoperable, and high scale DPI in your country – across agriculture, finance, health, education, skilling, ecommerce, and beyond.

To the builders and practitioners in countries tirelessly working to solve large scale societal problems: this wiki is dedicated to you.

We hope it can help bring you closer to your implementation goals.

Send us your dashboards so we can celebrate with you!

With warm wishes,

Kamya Chandra | Vijay Vujjini

Anusree Jayakrishnan | Tanushka Vaid

Citation guidelines:

Centre for DPI. (2024). [Title of the Article]. DPI Wiki. Retrieved from https://docs.cdpi.dev/

For example:

Centre for DPI. (2024). Understanding DPI. DPI Wiki. Retrieved from https://docs.cdpi.dev/understanding-dpi

Overview (What to aim for)

We cannot predict the future, or predict all scenarios to build a full stack, end to end digital solution - for example, a website, portal, or app - that fully meets the needs of a diverse and dynamic population. Unfortunately, a full solution approach assumes just one solution will fit everyone or just one entity/institution can build for all.

Instead, this principle necessitates technology architects unbundle problems and solutions to core, modular, minimalist, and reusable building blocks with open protocols and specifications to connect them. These building blocks should create high trust and low costs for other public and private entities when re-used. The ecosystem can then combine these building blocks to create many solutions fit for purpose (akin to lego blocks). Minimalism and modularity also allows each building block to be extensible to build or add on later as future technologies and capabilities evolve.

This ensures simplicity of the DPI, low cost/risk of building, ease of scalability/adoption, higher innovation around the DPI, evolvability to address future use cases, and avoids hard-coding and building of costly monolithic full stack solutions.

Maximalism creates complexity, high risk, and low innovation; cannot deal with future advancements; and most importantly drives exclusion.

Technical Tools (How to achieve it)

• Design of minimalist components, protocols/specifications that do NOT form a complete solution, but perform one function well.

• This means DPI architects should not overspecify data fields, forms of data, modes of use, types of authentication, etc.,

Societal Outcomes (Why it matters)

• Feasibility & Success of digital intervention

• Privacy

• Combinatorial innovation

• User-centric solutions

• Financial sustainability (lower cost of the DPI)

• Evolvability & Extensibility

The term digital public infrastructure is primarily used in two ways:

1. To describe an approach to addressing socio-economic problems at population scale. This approach combines open technology standards with robust governance frameworks to encourage private community innovation to address societal scale challenges such as financial inclusion, affordable healthcare, quality education, climate change, access to justice and beyond.

2. To describe real-world examples of that approach as represented by well-designed population scale infrastructure that abide by the principles of the DPI approach. India's digital identity system 'Aadhaar' is called a DPI, the Brazil payments system 'Pix' is called a DPI, Estonia's data-sharing platform 'X-Road' is also called a DPI and so on.

Digital Public Infrastructure - or DPI - is a phrase now regularly referenced by government officials, think tanks, development institutions, nonprofits, and even global CEOs as a transformational approach to leapfrog progress at scale. Countries like Brazil, India, Singapore, Australia, and Thailand have all built and scaled DPI. As with any rapidly evolving construct, every new project and experiment around the world slightly alters what people mean when they use the phrase. At the Centre for DPI, we'd like to put out our thinking to help countries answer the question: what is this magic sauce that you call DPI, and how can it fast track our national digitisation plans to create inclusive and innovative digital economies?

To answer this question, it's useful to first look back. The DPI movement is inspired by the open standards & specifications that created the Internet (TCP-IP, HTTP, HTML, SMTP, etc) and mobile networks (GSM, SMS, LTE, etc) - which operated as the original digital infrastructure of the late 20th century, triggering a burst of public and private innovation that broke barriers and drove inclusion. Our controversial opinion: No other tech innovation in recent memory - not the iPhone, not a laptop, not even a computer chip - has triggered as much subsequent innovation as those original open standards. Read that again slowly.

So looking ahead, how do countries take a similar approach that can catalyse inclusion and innovation in their nations in areas like access to money, access to health, access to education, and competitive innovation in services?

The DPI approach is about moving from platforms to open networks powered by protocols. We think there are 5 foundational categories that make up 21st-century digital public infrastructure: identifiers and registries; data sharing and AI/ML models; trust infra; discovery and fulfilment; and payments.

For a thriving digital economy, these are the functions that should be conveniently accessible at low cost. And fortunately, unlike the mobile and internet, these DPI require even less complementary hard infrastructure (wires, cables, cell towers, etc.) to create scalable impact.

These categories are not intended to be mutually exclusive! Payments on some level is a type of data sharing. Digital signatures (Trust infra) are used in ID/Payments/Data/Discovery and beyond. Consent (Trust infra) should be used in ID and in Data exchange. These categories are simply to indicate areas to focus on when crafting DPI!

Examples of how these DPI blocks can supercharge interactions in society:

1. Identity Verification: With an individual's consent, any entity can verify their identity (confirming "Are you who you claim to be?") through the eAuthentication capability. Additionally, basic information can be collected through eKYC ("Can you provide more details about yourself?"). This process helps reduce costs for services such as banking and insurance.

2. Payments: This system enables anyone to make digital payments to others, including street vendors who may lack digital or financial literacy, by simply scanning an interoperable QR code. This helps the conversion of a cash-based economy to a digital economy. The integration of digital identity and payment systems also allows governments to efficiently distribute social benefits without leakages.

3. Data Sharing: It enables individuals or entities to verify the authenticity of certificates and licenses by scanning digitally signed QR codes for high-trust, tamper-proof personal data sharing. Furthermore, it facilitates real-time, consent-based data sharing between systems, thereby reducing the cost of services like lending. Data sharing also includes creation of publicly available datasets for research & analytics available via open APIs

4. Trust Infrastructure: This allows individuals to interact and transact without needing to be physically present or use paper, utilising digital signatures and public key infrastructure to ensure secure transactions.

5. Discovery and Fulfilment: This allows any product or service to be discovered and fulfilled across multiple applications, whether it's discovering a lawyer or a telemedicine provider and booking an appointment with them, choosing a mode of transport, or even searching and applying for scholarships.

Many different building blocks in each of these categories can drive exponential outcomes within and across various sectors.

...by creating ecosystems that combine 1) the right technology architecture; supplemented by 2) governance frameworks that are transparent, accountable, participatory; and 3) robust public and private market innovation.

In each of the sections below, we'll cover specific building blocks that fall into these categories, and link to open blueprints/specifications your country can use to kick off the transformation.

Let's dive in.

Overview (What to aim for)

1. Build an architecture that operates on optimal ignorance - each system should know as little as possible.

2. Ensure high auditability and traceability via digitally signed data, non repudiable change logs, and authenticated transaction trails - even for agents/employees of the hosting department(s).

3. Build and leverage participant registries (individuals, entities, things in future) as independent building blocks to create higher trust and auditability.

4. Adopt verifiable credentials to increase trust within the system and also enable information verifiability.

5. Enable structured, granular, and auditable consent artifacts and frameworks to enable sharing of personal data across systems.

6. Multiple factors of authentication/ authorisation

Technical Tools (How to achieve it)

• Tokenisation & Masking: Tokenisation replaces sensitive data (such as an ID number or address) with non-sensitive equivalents (tokens) and masking hides parts of the data to reduce risk of unauthorized access/unecessary exposure while maintaining data usability for certain purposes.

• Granular electronic consent: A system where users can give specific, detailed permissions for the conditions of use, sharing, and processing of their personal data, allowing them to control which data is accessed, by whom, and for what purposes, thereby enhancing privacy and compliance with data protection regulations. Preferably the consent should be logged in machine readable, digitally signed format to ensure trust.

• End to end encryption: A method of data protection where information is encrypted on the sender's end and only decrypted on the recipient's end, ensuring that the data remains secure and unreadable to any intermediaries (including service providers) throughout its entire transmission process.

• Digital signatures: Cryptographic mechanisms used to verify the authenticity and integrity of digital messages or documents, ensuring that the content has not been altered/tampered with, and confirming the identity of the sender.

• Verifiable credentials: Tamper-proof digital certificates issued by multiple authorities (e.g., for identity, education, income) in machine readable formats that use digitally signed QR codes or soft copies to ensure authenticity without requiring centralized storage, thereby enhancing security and autonomy.

Societal Outcomes (Why it matters)

• Trusted usage of the DPI by individuals and entities

• Cybersecurity and reduced surface area of cyber attacks

Overview (What to aim for)

Avoid centralisation. Allow for federated databases/systems where possible that are each reusable & accessible by the individual (multiple functional identities, modes of payments, sources of data etc.). This prevents creation of honey pots (cybersecurity risk) and over-aggregation of information into unwieldy large central databases (a privacy risk).

In today’s world, it is perfectly possible to connect various systems via common protocols and standards and still achieve unification without centralisation.

A lot of people think that having a central system with high security is actually better than having multiple decentralised systems that are interconnected. However, this has proven to be false. Simply put, any central system or storage becomes a honeypot that is the repeated target of multiple cyber attacks. Decentralised systems function as lower value targets and strengthened by the best principles and practices of DPI, they become highly secure with very low chances of large scale data leaks or privacy concerns.

Technical Tools (How to achieve it)

• ”Wrapper” APIs above disparate existing systems rather than new large centralised databases.

Societal Outcomes (Why it matters)

• Autonomy of Institutions

• Cybersecurity

• Individual Privacy

• Resilience - avoid overdependence on any one system

Overview (What to aim for)

A DPI should not just be innovative in itself, but also enable diverse innovation by a public/private ecosystem of users.

A DPIs tech architecture should allow others (public and private innovators) to build solutions and services using the DPI at scale (akin to highways or the Internet) via tools such as open APIs (instead of DPI providers building the entire solution in a monolithic fashion).

Enable innovation both by ‘challenger’ market players in the ecosystem and by incumbents.

A digital back-end shouldn't presuppose a single digital front-end. Enable both the core DPI architecture and a diversity of innovative ecosystem-created solutions to power multi-modal access: across online, semi-online (low bandwidth connectivity), and offline modes; self-service and assisted modes; and in smartphone/feature phone/ no-phone modes.

• For instance, payment systems or identity systems shouldn't presuppose just one mode of authentication (e.g. online API based) and allow for offline or semi-online modes (QR codes, local SDKs that can perform face authentication, etc.)

This is essential to catalyse private innovation that doesn't merely target an elite connected population in a country, but also innovates to solve the challenges of diverse populations who speak multiple languages and have varying levels of digital literacy - thus reducing the impact of a digital divide. The principle also addresses both scale and adaptability/sustainability over time.

Private Innovation can be leveraged both in building the DPI (for instance, in driving private partners to enroll individuals into an identity system) and in usage of the DPI in a wider digital economy to offer solutions (for instance, banks or private players using an identity eKYC to offer a service like opening a bank account).

Public/private adoption and innovation should be voluntary and demand-based rather than mandated by authorities. This tends to create sustained usage over time.

Technical Tools (How to achieve it)

• Open Application Programming Interfaces (APIs)

• Digital signatures (Public Key Infrastructure)

• Digitally signed QR codes (available offline)

• Machine readability of documents

• Reusable Software Development Kits (SDKs)

• Data & other Standards

• Multi-modal access

Societal Outcomes (Why it matters)

• Inclusion

• Scale

• User Choice

• Resilience

• User-centric solutions

Overview (What to aim for)

Accelerate network effects to drive innovation and competition with technological specifications, protocols and standards for various functions that enable interoperability across multiple actors. Prevent silos, fragmentation of networks, monopolisation, and walled gardens by design.

Technical Tools (How to achieve it)

• Published protocols & standards/specifications for the ecosystem to adopt and comply with.

Societal Outcomes (Why it matters)

• Choice of solutions and services for individuals

• Scale of access and adoption for individuals

• Competition in markets while remaining interoperable

• Innovation by market players to drive differentiation of their service

Digital Public Goods (DPG) and Digital Public Infrastructure (DPI) are two distinct yet complementary concepts.

As described in the UN Secretary General’s Roadmap for Digital Cooperation, digital public goods are:

However, not all Digital Public Goods can be used as building blocks for DPI.

DPI can be built through open source (or private solutions) only as long as they adhere to open specifications, generate network effects, and trigger both public and private innovation.

DPGs having their own lifestyle and governance means that DPGs are set up by independent institutions that can predate or outlast country specific DPI. They have their own governing bodies and mechanisms to update their infrastructure outside country context.

Using open source components can help ensure that best practices are incorporated, rapid deployment and scale is achieved, dependency or lock-ins are avoided, and minimum efforts can unlock maximum gains. OpenG2P, OpenSPP, or CoreMIS for government benefits or MOSIP for identity projects are examples of DPGs used to help build DPI infrastructure in countries.

However, DPI can equally be built without DPGs or any Open Source components as well, though it may take a little more time, money, and expertise. Governments can choose to build their own DPI from scratch by using proprietary software, and private vendors - as long as they follow the principles of minimalism, interoperability driven by shared specifications, federation, inclusion, privacy, and security.

Even if a country is using proprietary software, it should still use open specifications. For example, regardless of the software used, it would incorporate ISO standards for payments or G2P connect specifications for G2P service delivery to ensure interoperability or choice for users, and avoid vendor lock-in for institutions.

At CDPI, we respect the autonomy of countries to choose whichever path (open source, private, hybrid) that suits their unique needs, and work with countries that opt for any path.

Our suggestion is that even if a country wants to build their own infrastructure from scratch - please always review the open source components available, and ask the private TSPs to ensure that all best practice features available in open source are incorporated into the private systems built. Open source is a useful benchmark, even if not used directly. This can ensure that country designers get the best of both worlds, and keep up with the latest developments in the community.

For suggestions on which open specifications and open source you can reuse to build different DPI, please see here.

1. Frame the problem clearly. The lack of growth of a specific digital program or solution is not a societal problem. Identify the real and root needs of individuals and businesses and gaps in service delivery to see where DPI can help intervene to create exponential change..

2. Think through why existing ecosystem players act the way they do. Mapping current incentives and current costs is crucial to understanding how to create change for the individual - DPI's aim is to change the calculus for ecosystem players who can now offer better services. What will it take to get them to do things differently? What are their real bottlenecks and costs?

3. Don’t aim for perfection before beginning. Universal adoption or aligning all partners on board (especially large incumbents) is almost never possible at first. Start anyway with a ‘coalition of the willing’ as early adopters and build from there - more will come over time. Asynchronous adoption is par for the course. Target some political support eventually, but it's not always possible to get whole-of-government alignment at the start.

4. Don’t leave all of the ‘how’ to technology vendors. Think through blueprints which include interoperability standards that create boundaries and roles for technology partners where they can excel, rather than outsourcing all of the design thinking to a tech partner. At a standards/blueprint level, tech is conceptually simple and accessible for strategic or policy leaders and doesn't require a Masters in Computer Science to take decisions on!

5. Small improvements (+1) Thinking to drive adoption. Rather than launching grand new projects or initiatives, ask what small (+1) changes across systems and ideas that already exist can help convert an existing digital system to a DPI to improve feasibility. For instance, an existing paper certificate can operate as DPI for a digital economy with a digitally signed QR code!

6. Small teams, high ownership. Particularly in early phases, DPI execution typically requires small teams that drive actions across an ecosystem, rather than unwieldy large central teams with dispersed ownership.

7. Design for system failures: Treat power outages, misaligned incentives, connectivity gaps, and other constraints as not the exception but as expected - and build multi-modal options and safeguards to ensure resilience.

8. Design architecture for tomorrow, but implement use cases for today based on political will & societal demand. For instance, you should architect a payments system that allows for multiple currencies in its root protocol even if cross border is unlikely on day one; or you should allow for multiple modes of authentication in a data sharing ecosystem even if one mode is the default based on current technology.

9. Frame adoption arguments from the counterparty institution's or user's point of view, not from the DPI builder point of view. Adoption by multiple stakeholders with different institutional positions and interests is essential to DPI. A market player, a regulator, a government department, or may have a different reason to adopt a DPI building block - frame it from their goals and interests or from an individual user's perspectives rather than yours. The value of the DPI to their goals should be explicit and clear in your narrative.

10. Parallel rather than consecutive phasing. It is tempting to wait for one phase to complete before beginning another - e.g waiting for ID registration to complete before testing authentication, or waiting for registries to be completed before building transactions/ service fulfillment networks in a sector. But if you have minimised the components of DPI to bare essentials, build them out in parallel as much as possible to avoid late surprises.

11. Multiple bets for the first DPI block. While implementing the first DPI block always pick more than one, say three potential use cases and three first adopters. Pursue all 3 in parallel for a higher chance of successful implementation

12. Test and debug early. No digital project is perfect on day one. Your DPI may get to 40-50% coverage based on high quality architecture and design, but will not reach critical mass without consistent bug fixing, catching errors, and continuous improvement. Seek constant market feedback on the usage of the DPI, especially in early stages. Target early sampling, testing APIs in sandboxes, small pilots, and hackathons as well as drive consultations with key players to ensure iterative improvements of the approach and wide adoption at scale.

13. Leverage existing digital assets in the country and/or global open source where possible. Try to reuse existing digital assets in the country - existing certificates, databases, or systems to see how small changes could help them operate as digital infrastructure (i.e. be reusable!) in the wider digital economy. If you're building from scratch - the quality and availability of open source in this space has taken a leap in the last few years - take advantage of it to build faster and cheaper. If you prefer to build in-house or via a vendor, ensure your system reviews and absorbs relevant learnings from available open source models.

14. Impatient with actions, but patient with results. Large scale societal transformations may take time (especially at the start, when the progress seems invisible) before developing enough ‘escape velocity’ to scale. Be patient while staying determined to make the next right step.

15. Be prepared to act fast in policy windows. It is crucial to work consistently on a DPI, build a coalition, and demo/test building blocks even when there is no policy window or political will in sight. Only the prepared can take advantage of an unexpected opportunity, crisis, or other policy window to drive scale-up!

16. Don't charge on day 1: Let adoption scale before adding in an additional cost to the user, it will reduce friction and hesitancies. Let them see the benefits of the DPI before so that they are willing to pay for that convenience.

17. Establish a volunteer policy: Many public-minded people will want to help in whatever capacity they can!

18. Early market feedback and co-creation: Organise hackathons, consultations, etc. to gain feedback from the start. Build with the market even as you build for the market.

19. Don't underestimate governance: Remember, the best tech has to be supported by strong governance frameworks from the start to nurture market innovation and private competition in the right spirit.

20. Minimise your role: DPI is built through humbleness! Focus on doing one thing and do it well. Always frame the other departments / people's contribution as more important to make them feel like a part of it and join you on the journey.

21. Expect a rocky road: Work with challengers, and wait for incumbents. As long as you stick to it, you will get there in the end!

What DPI can I build if I am a ...

Central Bank or Financial Regulator:

1. eKYC policy to encourage use of digitally signed credentials under boundary conditions

3. Upgrade to a modern & programmable payment protocol (P2P/P2M) allowing fintech to innovate on UX whilst keeping money flow with financial institutions

Department with an ID (National ID, tax ID, drivers license, birth certificate, etc):

a. eKYC: Share key profile data fields with ecosystem players via verifiable credentials or eKYC APIs

b. eAuth: Add electronic authentication

c. eSign: Allow people holding your ID to remotely & paperlessly sign any document

d. Single Sign On: Allow people holding your ID to sign in to any other public/ private system (akin to ‘sign in with Google’)

A Payment Switch Operator:

2. Upgrade to a modern evolvable programmable payment protocol for all kinds of payments (P2P/P2M; G2P, retail) This protocol should allow for innovation in use cases as well. (recurring payments, vouchers, credit etc.)

Social Protection Benefit Program Manager:

IT Authority/Digital Economy Ministry:

3. Publish an open API policy to encourage individual departments’ API publication for various services (like tax filing, beneficiary enrollment, etc.) openly available. This can be integrated into the workflows of other applications for maximum utilization.

4. Open API for Govt Services: Encourage Govt. departments to move from single window portals to open up their APIs to enhanced user experience and service delivery.

Finance Ministry:

Commerce/Digital Economy Ministry:

Tax Authority:

1. Open up APIs for tax filing to third parties to reduce failure rates and increase compliance.

1. Registries (Professionals, Facilities, Drugs): Allow access to verified, machine-readable, digitally signed data to any public or private innovator.

2. Virtual Health Address: Linking health records and identifying an individual in the healthcare ecosystem

3. Open claims network: Publish a specification for a machine-readable insurance claim to power fast, efficient, and automatic claims processing to reduce out-of-pocket expenditure

4. Open Health Network: Use an open networks protocol that allows anyone to discover any service on any platform using any app with telemedicine as the anchor use case (Also supports e-pharmacy, ambulance discovery, appointment booking etc.)

Supreme Court/Justice Department

1. Open discovery of lawyers and associated services (hospitals, police stations, therapists, trauma care providers)

2. Open APIs for assisted case filing and online tracking of cases

3. Anonymised access to legal counsel through interoperable apps and tele-law

Agriculture Ministry (click here)

1. Registries

2. Open networks for discovery & fulfillment (of produces, idle capacity like machinery, land, energy sources)

Private Bank/ Public sector banks:

1. Use the open banking framework to gauge the creditworthiness of an individual/ establishment based on previous financial history and future cash flows

Private Hospital:

Private Employer:

2. Can integrate with ID account mapper to seamlessly process employee payrolls

If you are an individual:

1. You can contribute to open source that builds DPI globally

2. To work on DPI tech and policy in India please reach out to CDPI for ongoing work in finance, justice, energy, agriculture, healthcare, and beyond.

It is famously said,

"Building DPI requires deep conviction and not deep pockets."

Some DPI cost the taxpayer almost nothing!

When people talk about 'Digital Public Infrastructure', they typically imagine large-scale national ID projects, or digital payment networks. While these both are critical aspects of DPI, they are not the only options. Many of DPI blocks in fact are small +1 components that can be added on to existing infrastructure in the country to convert them into high-functioning population scale resources. DPI can also be updated to existing standards and protocols that allow the market to function more effectively and inclusively.

If a country adopts a standard and orchestrates its adoption by the ecosystem, it can drive an interoperable open network for various capabilities such as - for data sharing (for credential issuance schema, or for registry access APIs, or for consented personal data sharing); or for discovery and fulfilment (publication of open APIs for government services including filing taxes; open standards for discovery of any good or service (such as BeckN); or payments (publishing interoperable QR standard for market to follow; cash in cash out standard for interoperable cash withdrawal). Once the new standard is agreed upon, then the team in charge just has to review the existing standards and publish a paper outlining the update.

This is a 3-4 week process with little additional technical implementation cost for the government.

Other digital public Infrastructure can be brought to life in a country in two ways:

1. Greenfield DPI implementations: when the entire infrastructure is built from scratch through a fresh private procurement route

2. Rapid DPI upgrades: when existing infrastructure is enhanced with +1 blocks to convert them into powerful DPI. For example, converting an existing physical or digital ID or document into a digitally verifiable identity by including a digitally signed QR code on it, or converting a large database into a registry by opening up its APIs for others to use.

The costs associated with both these approaches can vary significantly

1. Greenfield systems from scratch

The cost of building a national ID enrolment/registration and database management infrastructure, for example, under the first approach would be a multi-million dollar investment plus some fixed costs of maintaining the system.

Similarly, the startup cost to build a P2P / P2M payment system from scratch would typically be less than 7 million (plus maintenance costs annually), requiring investments from a consortium of banks if a payment switch operator is driving it (or by the central bank if they choose to operate it themselves). These costs typically have an extremely high RoI as mature payments systems move billions of dollars in commerce monthly/annually.

2. Rapid Upgrades to existing Digital Assets

Yet most countries aren’t starting from scratch. Improvements to existing fast payments rails to support payments systems to operate as DPI (e.g. by inserting a QR code specification to make existing wallets and payment providers interoperable; upgrading the API specifications to allow third party app payment initiation; introducing a standard mode of authentication for third party apps to complete payments; creating multi-party dispute resolution via open APIs; etc. could cost only a few hundred thousand dollars for the entire project (including tech and program costs) depending on the design and other variables.

Countries often already have some type of physical or digital infrastructure in place and hence fall under the second category for most DPI implementations.

Based on our costing model, “Conversion” DPI building blocks such as verifiable credentials (data sharing), ID auth / eSign / eKYC (layers on top of ID), G2P mapper (payments / social benefit delivery) would typically require around $750k +/- 15% (depending on the country context) over six months to roll out a high value and reusable DPI at scale when built on existing systems.

Extending or deepening the implementation to add additional use cases over a 12 month period (illustrating the multi-domain impact of DPI) could cost around $1.3 Million (+/- 15%) in total. The costs of augmenting national P2P/P2M payment systems varies more based on the scope/capabilities of the existing system.

In case countries wish to build these blocks to demonstrate quick wins with powerful last mile benefits, they could also consider the DaaS Program and receive support from private philanthropic sources and open source DPI packages necessary to roll-out these capabilities.

1 minute read: +1s to transform your digital strategy into a DPI strategy:

Countries all around the world understand the need to digitise their economies. The arguments for speed, efficiency, access to remote areas, and enhanced transparency are well-documented. As the penetration of data, mobile devices and internet connectivity increase, digitisation has rapidly evolved from being a ‘good-to-have’ feature to a ‘must-have’ necessity, in order to keep up with the developing world.

As a result, many governments are drafting digital economy or digital transformation strategies to keep pace with this evolution. However, concerns around privacy, security and inclusive access still remain, with many countries in the global south facing a higher risk of systemic exclusion of their last mile populations in case a whole-of-government digital transformation effort is undertaken. Fears of loss of privacy and security through misuse, mismanagement or leakages of data are being voiced by countries across the globe, placing governments at the centre of a precarious situation. Should they digitise (investing heavily in the process) and risk the aforementioned outcomes, or should they continue to operate as per current norms and risk the opportunity cost of non-digitisation?

Thankfully, as many countries such as India, Singapore, Brazil and others have shown, the balance between an individual’s privacy and institutional digitisation can be achieved through well-designed Digital Public Infrastructure (DPI) approaches that also guarantee access and inclusion for last mile populations. The principles of DPI include

1. Interoperability - ensuring the same rails can be accessed in a variety of ways and are not built in silos, such as by setting out a QR code specification that can allow for seamless digital payments from any store of value to any store of value

2. Minimalism - focusing on light touch interventions with high impact, such as by designing an ID project that contains only 4 basic data fields similar to Aadhaar in India, and doesn’t try to capture ‘as much data as possible’ which would make the infrastructure bulky and unsustainable

3. Inclusive innovation - allowing for private market players to build on top of the DPI in a regulated ecosystem. This will allow for diversity and quality in user experience such as accessing the same payment rails through a smartphone, feature phone, assisted modes etc.

4. Federation - the key to secure systems is through federation and not centralisation of data, such as by introducing an Open API policy that can allow for async and synchronous data sharing without needing to store it in one place

5. Security and Privacy - keeping individuals at the centre of systems and ensuring that systems can proceed only upon receiving explicit revocable granular consent by the individuals.

The expansion from a digitisation strategy to a DPI strategy consists of light-touch +1 steps that can be in-built into any pre-existing or newly built digital transformation blueprint. The main purpose of DPI is to ensure that:

1. The government can work towards asynchronous quick wins leveraging existing infrastructure with minimal cost / time / effort investments that unlock rapid benefits for individuals

2. All individuals (irrespective of diversity in financial, social, educational or accessibility backgrounds) can equitably access the digital rails built through their existing capabilities

3. Private market participation is incentivised to allow innovation over the government sanctioned DPI rails to simultaneously support overall economic growth and prosperity

These outcomes can be easily achieved through any well-designed DPI. Three tips to help convert a digitisation strategy into a DPI strategy are:

1. Focus on quick-wins alongside the larger digital transformation strategy: Often, the digital transformation strategy is a robust document requiring institutional establishment, policy changes, procurements, mandates, teams and more. This is a necessary though time consuming process. In parallel to this, the government could focus on executing smaller DPI pilots (such as verifiable credentials) that do not require new policy mandates, multi-department alignment or large procurement cycles. This will help demonstrate proof of success of the digital transformation mission by delivering benefits to individuals in the country and receive institutional support for the larger mission as well, once everyone has had a chance to see results on the ground.

1. Asynchronous adoption, instead of multi-department coordination, through proof of value: Sometimes a significant blocker faced by countries during executing a digital transformation strategy is resistance from various government departments to align and coordinate on a single approach. This can usually be difficult to resolve. It can be powerful to start rolling out DPI with the first-mover departments who have forward-looking individuals that are aligned with the approach and larger mission. Focusing on the DPI blocks that align with the mandates and budgets of those departments can help speed up the process of approvals and execution. Once a pilot or building block is live, other departments and institutions should be free to asynchronously join the rails as and when they see the proof of value it is offering the first-mover and its beneficiaries. One example would be to roll-out a government to person payment rails (through a G2P mapper) for the social benefit delivery that is aligned with the DPI approach as perhaps the agricultural ministry for subsidies to farmers for fertilisers. When the G2P rails are able to bring significant reduction in the amount of leakages, thus saving the overall department budget, other ministries or programs such as perhaps the food-subsidy program would also want to join the rails and so forth. Asynchronous adoption may seem more time consuming at the start, but it actually helps speed up the process of execution, and results in more sustainable and scalable infrastructure models.

2. Build on existing infrastructure as far as possible and not from scratch: It may seem that to build something in line with DPI principles of privacy and security, federation, inclusion or innovation, one has to build the infrastructure from scratch since current systems may not cater to some or all of the aforementioned principles. However, this is usually not the case. DPI by nature consists of minimalist, light-touch interventions that can rapidly increase inclusion and innovation at scale. It typically never advocates for long-procurement cycles or uphauling whole-of-government systems. It is more economical or effective to simply add a feature to existing systems to trigger inclusive scale. For example, if there is a physical ID card with 30% coverage of population, simply adding a digitally signed QR code to it would make it possible to include features like e-authentication, e-kyc, or single-sign as well. These three value-added features would immediately deliver value to individuals and institutions and increase the voluntary adoption of the national ID card.

Countries should avoid blind duplication of another country’s efforts. While it is always useful and important to understand the best principles other countries have adopted while designing their own infrastructure, and even having conversations with them to learn from their mistakes, all this knowledge must be adapted to each country’s unique socio-economic-political context before deployment. Another country’s hosting choices (both technical and institutional) might not show the same results when deployed in another country without proper contextualisation.

The balance between the elements which can be standardised (and must be, in order to save time, cost, effort and adopt global practices) and the surrounding program architecture that must be contextualised (to show success in the deploying country) must be achieved. One method of achieving this balance is through the DaaS Program that productises and packages the standardised elements while allowing for consultations with CDPI (and other advisory partners) to adapt those elements to solve unique societal scale challenges.

In fact, all these +1 steps can be live in as little as 90 days through the DaaS Program though they can also be built independently. The Centre for DPI stands ready to help advise on converting any digitisation blueprint into a sustainable, scalable, inclusive DPI strategy.

Question: Does DPI reduce personal privacy, increase security risks, or hurt public safety by increasing capacity for surveillance?

Short Answer: Well designed DPI actually improves your control over your own data, is minimalist in data collection (sufficient for access to services and nothing more!), opts for federation rather than centralisation of data, and builds security and privacy preserving features (such as tokenisation, auto data deletion, auditable and tamper proof logs of data access and use, etc.) by design. Successful national ID systems that scale for example, have a minimalist set of data fields so the chances of loss of privacy even in case of a data-breach is low - contrarily, the internet has millions of data points of any individual and much less safeguards (both technical and moral) to protect it.

Long Answer: Digital Public Infrastructure enables solutions to be built at scale - catering to diverse populations with varying levels of ability and resources, in an equitable manner. This scale and impact can ONLY be achieved by institutionalising data minimalism, privacy and security, and public trust into the systems (as DPI only scales with public and private adoption, which requires trust).

For example, design features of a country’s national (digital) ID system that preserve privacy and trust should include:

• Minimalism in data capture - The less data is captured, the less of a honeypot is created.

• Avoiding tracking - no collection of location/purpose in ID auth/eKYC

• Creating a Virtual ID or a token as a fungible alias for the permanent ID to avoid providing the actual ID number for services

• Authentication done with consent of the user (via one time password or biometrics)

• Usage audits which are permanently auto-deleted every n months

• End-to-end encryption for data at rest and data transport layers

• Allowing residents to lock their ID and/or biometrics, disabling authentication

• Unique tokens that are different for every system, eliminating the ability to merge databases

• Multi-factor authentication for high value transactions

• Advanced cybersecurity measures for database security, including periodic ethical hacker tests

Features of an interoperable data sharing system to drive enhanced privacy and security could include:

• Avoiding centralisation of data to prevent honeypots - letting data remain where it has been collected, and crafting protocols for real time sharing in a federated manner.

• Introducing the ability to query databases for a yes or no response as per a criteria or question, without always requesting the raw data for analysis

• Introducing a detailed, granular consent (purpose specific and data specific) artefact (digitally signed for added security) required from the individual to share data

• Allowing consent to be managed by a data-blind third-party who acts on behalf of individuals (not the information providers or information users) to ensure an actor with incentives aligned with the individual is showing them a consent request (rather than a data user or provider)

• A pre-specified time period for access to data - with consent revocable at any time by the individual

• Multi-factor, multi-modal authentication capabilities for signing in to the system

For instance, Brazil’s PIX has prioritized security in its payment system through a combination of technologies and regulatory measures: It uses encryption protocols, two-factor authentication to verify user identities and digitally signed transactions, with possibility to reverse payment within a certain time window. The financial network itself is not connected to the internet, and only restricted participants can actually access the database directly, in addition to regulatory oversight by the Central Bank of Brazil which ensures compliance with financial security standards and promotes user trust in the system.

Another example is Aadhaar - India’s ID system which collects only 4 minimal, constant fields of an individual - name, date of birth, address, gender. This means that the data is always accurate. Now what if they had collected 10 fields including profession, income, family members, etc? This could change year on year, making the data redundant. Collecting and storing that information would also make systems bulky and inefficient - affecting the speed and accuracy of all systems that use it (such as banks using ID data for eKYC).

If data privacy wasn’t guaranteed, and personal information could be shared freely across departments - for example, if the payments system could send information about your transactions to the tax authorities who subsequently showed up at your doorstep - would anyone sign up for those solutions? Likely not! And DPI would never be able to scale or sustain.

Evidence of its robust minimalism, privacy, and security is evident in the widespread adoption and long-term sustainability of critical systems like verifiable identities, interoperable payments, healthcare claims settlement networks, education credentials, mobility, and commerce networks globally.

While all technical systems face vulnerabilities, well-designed DPI anticipates and prepares for potential attacks. . If information from a minimalist system is leaked - information that is already more or less public such as your name, date of birth, gender, etc. - you stand to lose much less than when large systems are breached such as your internet history, social media footprints, email accounts etc. which have more damning repercussions. The fear of our internet accounts being breached doesn't stop us from using the internet, similarly, the remote fear of DPI systems being breached should never be a barrier to implementing beneficial measures at scale. We must simply build resilient, secure systems that can stand the test of time.

There are multiple ways to ensure data minimalism, security and privacy such as those outlined above. Similar safeguards can be put in place using a techno-legal approach for all solutions built through the DPI approach. These measures can solidify systems to reduce the probability that a malicious actor can use the systems to increase surveillance, or cause intentional harm.

Question: Does building Digital Public Infrastructure hamper the growth of a competitive economy?

Short Answer: Not if it is built in accordance with best practice design principles. DPI increases healthy, fair competition in an economy amongst players and triggers tremendous market value. DPI means public interest, not necessarily public ownership or execution.

Long Answer: The word ‘public’ of Digital Public Infrastructure is often misconstrued to mean that all components of the infrastructure will be owned and operated by the government, leaving little room for private sector players to build solutions and derive value. One hesitation in adopting DPI lies in the misunderstanding that it will obstruct the free flow of competition in a laissez faire economy, or crowd out the private sector from providing services.

However, there is much more nuance here. The word ‘public’ in DPI denotes that all solutions built, whether private or by the government, are in the best interests of the public. It signals that the individual should be at the centre of the economy and at the heart of all endeavours. The role of the government in DPI may simply be to lay out the rules which enforce this idea of ‘people before profits’ to nurture free and fair competition that is the backbone of any healthy society.

Every sport is played according to certain rules, and there are penalties for violating them - yet, we don’t look at these rules as obstructions to the game but rather as necessary guardrails which keep players safe and the game interesting. Similarly, the DPI game is about laying down certain rules - such as Interoperability, Privacy and Security, Federation, Inclusion and Minimalism - which act as guardrails to prevent monopolies, unfair practices, and dictatorial tendencies.

Not only does DPI allow for competition in the existing economy, it also creates new avenues for private sector growth and innovation. The analogy commonly used is that DPI doesn’t just allow more people to eat from the pie but it also increases the size of the pie so that everyone, including incumbents, get a larger market share in ways they could not have previously imagined.

DPI creates potential for competition at every level of its execution, adoption, and growth. For example, in Payments, the government attempts to build only when decades of market players trying to solve this problem have resulted in silos, exclusions and market failures. The government builds only the minimalistic rails and not necessarily the applications (innovation layer). The market players can build their own apps on top of the rails (adoption layer). Once you build DPI in payments, it also unlocks other layers such as lending where a new playing field for market players (execution layer).

The layers of private participation (in more detail) are:

1. Innovation Layer:

Once DPI has scaled, there are various ancillary services that can be built on top of it that leverage its benefits. For example, the interoperability and verified credentials gained through Open Banking (data-sharing as well as payments) create the foundation for Insurance, Lending, and eCommerce use cases to be built on top of it. DPI attempts to solve only the minimum bottleneck - e.g. verifying a few profile data fields - without entering the realm of final solutions or service delivery.

1. Adoption Layer:

Once the DPI has been built, it is only successful if it adopted by the market players to offer improved services to people of the country to truly scale. Every country has its share of diversity in the form of demographics, abilities, income levels etc., and no single platform can adequately cater to all of them. The second layer of the DPI approach - market innovation layer - pushes for private sector innovation and competition to cater to these different segments of society using User Experience as the key differentiator. By creating a level playing field, the DPI approach ensures that the best player wins on the basis of the value provided to the end user.

1. Execution Layer:

While the DPI approach can be triggered by the government, it actually requires significant private sector participation - typically via Technology Service Providers (TSPs) and System Integrators (SIs) to roll out the DPI on a nation-wide scale. This allows for innovation from and competition between various market players to offer the best contract and build at a country level using best practices for design and governance.

There is a widely popular anecdote from the Indian sphere in this regard. It is said that after India’s foundational identity ‘Aadhaar’ had scaled, and offered eKYC services on top of it, Amazon went to the Indian Government and requested for an Aadhaar for businesses!

Amazon said that the only way for them to accurately verify businesses that wanted to be listed on its e-commerce platform was through national, digitally signed documents for a business including the eKYC ability.

This is the perfect example to display that even the largest private sector players benefit from the DPI approach because it allows them capabilities and functionalities it could not have previously solved.

DPI solves for every last individual in the country - and this includes the individuals running private sector businesses!

Verifying ID & accessing profile data of people, entities, & objects is a crucial foundational function of digital economies. When moving from physical to digital interactions, the first complication is establishing trust as to the identity of the counterparty. It is crucial that this identity is verifiable: i.e. can be authenticated in some means (a mobile one time password, a digitally signed QR code, a biometric fingerprint scan, or even a face ID authentication).

A country should have multiple identities to fulfill multiple purposes and functions across sectors - but one or more of them should provide a foundational capability of authenticating that the individual is who they say they are, and returning a few commonly required data fields (such as name, gender, date of birth, and address) via an open API. Functional identities (such as voter IDs, social protection IDs, or drivers licenses) should also strive to make their profile data accessible via APIs or through other digitally native means.

An identity system is a registry of persons. Countries also need foundational registries of entities (such as businesses, hospitals, schools, etc.) to allow sector-specific digital service providers to innovate based on shared datasets. These registries should provide digitally signed data - to ensure it is tamper proof - and preferably via open APIs (and prevent clunky PDF or excel downloads) to ensure software can directly consume the information. This greatly enhances the speed of service delivery and the competition across sector specific market players.

Key examples of building blocks in this category of DPIs include:

• Authentication (Mobile, Offline QR Code based, Biometric, Face, etc)

• eKYC

• Single Sign On

• Civil/Functional Registries

• Entity Registries

• Object Registries (land,etc.)

Note: Whether or not something is a DPI should not be thought of as a yes/no checklist criteria; rather, a digital asset can grow in its maturity as a DPI for the ecosystem depending on the value addition and innovation potential it provides at affordable costs for both public and private use cases.

That said, below are some key technical features* that can help move certain key digital systems or assets further in maturity along the journey to becoming robust digital public infrastructure for the ecosystem.

*The list is non-exhaustive

If you’ve chosen which DPI block you would want to build, congratulations! The first step is done. Now, the second important question is, which use case do you want to pilot that DPI in?

For example, if you have decided to build verifiable credentials, your first use case can be making verifiable credentials for school certificates, or farmer certificates or driving licences and so on. For G2P mapper, this would mean choosing which social benefit program do you want to pilot with - pensions or gas subsidies or scholarships? For an AI assistant this could mean choosing which sector you would want to simplify first - is it access to justice, or agricultural extension services for farmers, or health scheme and insurance information?

And in case you are wondering if the first use case really matters - the answer is a resounding yes! Through the first case, you will be able to establish proof of concept and proof of success of the DPI approach in your country for that block as a whole. It is a critical move that will align different stakeholders as well as individuals of the country at large with the new DPI method of doing things. Uber launched in most emerging economies with Mercedes cars; the first impression matters and should build immediate traction to solve a pain point..

Below are three simple questions that you can answer to lead you to choosing a powerful first use case for your DPI block.

Which use-case is…

1. Regularly used by individuals as a ‘toothbrush’ use? Or addressing a big-enough pain point?

For example, do people regularly need to show their income certificates to get access to various programs and there is no way to verify them? Is the pension scheme a large enough program through which money is transferred every month but there is no way to map the accounts it is going to? If this is true, then it is a good first use-case! On the other hand, converting school certificates into verifiable credentials (that someone may hardly use in their lives) is not necessarily a powerful first step. Try to select a use-case that addresses the daily needs of the common man. This way there will be a big enough pain point that people are willing to try something new in order to find an easier way to navigate that situation, and the willingness to adopt the DPI will be higher.

1. Covering large amounts of the population?

It is ideal if the use-case has a large enough coverage in the country so that it can create meaningful impact right from the start. For example, turning vaccine certificates into a verifiable credential is something that affects everyone in the country, as does receiving subsidies for food or gas. The larger the coverage of the pain point, the faster will be the voluntary adoption of the DPI. If a very niche sector is chosen as the first use-case it will be difficult to apply it cross-sectorally or use it as proof of success for a larger population.

1. Aligned with their line ministry on the DPI approach?

The last important point to consider is whether the line ministry in charge of that use case is also aligned to the DPI approach or can be efficiently brought on board. For example, for verifying land records, is the home ministry alright with sharing the land record database? For routing G2P for educational scholarships, is the education ministry alright with sharing student records? Knowing you have the agency over or approval of the line ministry required to execute the DPI block for this use-case means that you now have a winning formula in your hand!

Note: The first use case is different from first adopter!

For example, the first DPI block can be data sharing, the first use case for data sharing may be bank certificates, and the first adopter of the DPI use case may be a digital lender who uses it to approve a small ticket loan!

Similarly, the DPI block can be Open Discovery, the first use case for open discovery can be mobility, and the first adopter can be a ride sharing startup who wants to integrate it into his platform.

A powerful combination of these three factors (first DPI block, use-case and adopter) is the winning formula to help ensure your DPI is successful.

Happy building!

There is a flurry of activity in the DPI ecosystem: governments are building DPI from scratch, open-source projects and digital public goods (DPGs) are developing DPI solutions, funders are supporting DPI implementations, and private vendors are marketing their DPI projects.

However, not everything labeled as DPI truly functions as such. How can you quickly identify whether a system or solution is a genuine DPI architecture?

Before diving in, let's recap a few key points:

• Open source does not automatically mean DPI, nor do DPI implementations need to rely solely on open-source solutions.

• DPI implementations must use open APIs, open standards, and open specifications to achieve interoperability and reusability.

• All DPI implementations are designed to be reusable by third-party public and private institutions, and not just beneficial to the implementing institution.

• Every DPI implementation must adhere to and internalise five key technical design principles

Note: Whether or not something is a DPI should not be thought of as a yes/no checklist criteria; rather, a digital asset can grow in its maturity as a DPI for the ecosystem depending on the value addition and innovation potential it provides at affordable costs for both public and private use cases.

That said, below are some key technical features that can help move certain key digital systems or assets further in maturity along the journey to becoming robust digital public infrastructure for the ecosystem.

1. Digital ID system:

• For a digital ID system to function as a DPI, it should have an ID authentication layer. This means the system should be able to process requests and return yes/no answers for verification requests.

• For inclusion, implementation can also support multiple authentication modes (known as multi-modal authentication) for further inclusivity. For example, online (auth API, email one time password), 2G connected (mobile one time password) and offline (verifiable QR on paper) modes, multiple modes for biometric auth such fingerprint matching, face matching, iris matching, etc.

Additionally, more mature ID systems should enable the following capabilities:

• eKYC (API-based profile data sharing based on a successful authentication for ease of onto external public or private services)

• Single Sign-On (enabling login to other public or private goods and services via the ID)

• e-signing (replacing a wet signature with an ID-enabled electronic signature), which all help trigger a high-trust digital economy)

1. Registries containing personal data:

Registries are one of the most common digitisation implementations, often understood as simple databases.

A registry implementation can be considered a DPI if it stores data

• in a machine-readable,

• digitally signed format

• that external parties - both public and private - can access

a. The first and simplest way to enable data sharing using registries to generate verifiable credentials for the holder as a natural exhaust for the stored data.

b. Registries operating as mature DPI can also enable access system to system directly via open APIs. These open API standards can come from self-defined national standards or derived from well-accepted open specifications like the G2P Connect/ DCI APIs.

1. Digital Payments Infrastructure :

a. Peer-to-Peer/Person-to-Merchant (P2P/P2M) Payments

Often, instant bank-to-bank payment systems are packaged as DPI implementations. However, for a P2P/P2M payments infrastructure to truly operate as DPI, it should be

Inclusive: The infrastructure should have scaled to usage by the majority of the population without significant cost or technology barriers

Interoperable: To operate as a mature DPI, a payments rails should support the movement of money across:

• Any account used for payment (Bank, Wallet, Mobile Money, Credit Lines)

• Any app used to pay (Bank, Wallet, Mobile Money, Fintech)

• Any device or channel (Feature phones, PoS machines, Smartphones, QR stickers; Online/Offline, Dynamic QR)

• Any recipient of payment (P2P, P2M, P2G, G2P, etc.)

This represents the ideal (though evolving) state of nature payments DPI. Countries do not need to build all of this on day one though - they can add capabilities as they build, but the initial architecture should be future-proof, programmable, and easily extensible allowing ease of addition of new features.

b. G2P Payments

Government-to-Person (G2P) benefits is a complex ecosystem with many modules, including scheme management, beneficiary management, disbursement systems, settlement systems, and last-mile cash-in/cash-out systems, all spread across various departments.

G2P systems can operate as DPI by utilizing reusable infrastructure, such as registries, an ID-Account mapper, and cash in cash out standards.

• Collected beneficiary data can be converted into a registry for reuse by other departments (see #2 on registries).

• An ID-Account mapper (a four-field registry mapping a verifiable ID or phone number to an account number) can be used to route payments without repetition.

1. Data sharing infrastructure - Personal :

a. User-centric Verifiable Credentials

Digitally issuing PDF certificates in a dedicated app or platform is not considered a DPI approach on its own. Credentials operate as DPI when they are digitally signed, machine-readable, and can be shared with and verified by anyone. Adding a signed QR to a PDF certificate is a quick and simple way to convert a digital certificate to a DPI. For more mature data-sharing DPI, the API standards for sharing credentials and the schema for defining the content should be harmonised at a national level.

b. System to system Real-time data sharing networks

A centralised data warehouse or repository of personal data is not typically considered a DPI (unless crafted as a Registry above). The DPI approach involves creating federated, open data-sharing networks where any data consumer or provider can plug in to receive or share data as per the network's rules. It is highly recommended to collect user consent as part of this flow. Open API standards (for data sharing) and schema will need to be defined at a sector/ national level.

1. Data Sharing Infrastructure - Anonymised Data:

Uploading PDFs or Excel files in bulk for public consumption is not usually considered DPI, because of its low reusability potential. Anonymised aggregated data should be made available to third parties in a machine-consumable format with APIs for access. Permissions and licensing terms can be set on these data sets.

1. Unifying government Services :

Many governments use an Enterprise Services Bus (ESB) solution to unify the various services provided by the government into a single-window application or portal. While this architecture is useful, it is also very complex, difficult to maintain and scale, and requires interdepartmental consensus.

The DPI approach would be if each department would open its APIs for a service and publish them for third parties to consume and integrate into their workflows. The Department of ICT, for example, could compile all these open APIs and make them easily accessible for integration.

Alternatively, existing government services buses could open up collectively the APIs for all the services they have aggregated.

Note: This article only discusses technical metrics; Good, participatory governance and inclusive market innovations are equally crucial for a DPI implementation

Question: Is mandating adoption necessary to achieve scale for various Digital Public Infrastructure building blocks?

Short Answer: Typically not. While sometimes mandating adoption may help speed up the process of achieving scale, in the long run, voluntary adoption based on a strong value proposition to all market players and citizens is more sustainable at driving impact. DPI-builders should prepare for asynchronous adoption over time starting with smaller players, rather than wait for the largest incumbents to agree before launching.

Long Answer: Countries are often faced with this dilemma: there is often hesitation or reluctance on the part of market players or existing institutions of the country to upgrade to a DPI approach, or apathy of individuals in accessing or using the DPI (such as with digital identities). They may be sceptical of the value it would provide them, or have vested interests in previous legacy systems.

Mandating adoption may feel like a faster solution in some cases; and there is proof that it can be effective in the short run - particularly in regulated sectors where a regulator or government entity can enforce changes. However, a mandatory implementation approach can also lead to increased resistance by institutions towards infrastructure or approaches that are seemingly forced upon them by the authorities, or create a ‘checkbox implementation’ syndrome where the DPI is adopted in name but is not done with high quality. For instance, regulators sometimes mandate the use of open banking APIs - but banks could implement them with low success rates, effectively meeting the compliance burden without changing consumer experience.

Moreover, mandating DPI adoption leaves the system vulnerable to policy changes. If the policy leadership changes a few years down the line and they reverse the mandate, all the momentum achieved may be lost. Finally, if it is mandated, market players may view it as a compliance issue and not necessarily devote their best talent into it.

A more sustainable option would be to encourage voluntary adoption of the infrastructure at scale. This can be done simply by making DPI building blocks immediately useful for the individuals and institutions so that they can clearly see benefits, reduced costs, improved efficiencies, or market value of adopting it. DPI can be designed with strong incentives to adopt for all stakeholders.

Some examples are:

These features reinforce the spirit of the DPI approach to keep the individual at the centre of all systems and to only move with an individual's consent and interests at heart. When the incumbents realise that the DPI is not eating into their market share, but rather offering them more opportunities for growth and success, they will automatically want to join in. DPI does not just allow more people to have a share of the pie, but it also increases the pie so that everyone may have a larger share. This may not happen at first, and ecosystem facilitation adoptions should be comfortable with an async adoption pace with small challenger organisations going first and larger ones joining in later.

This gesture of allowing voluntary adoption also builds a layer of trust between governments, institutions, and people. It carries an intrinsic layer of faith that the DPI solution is secure, futuristic, creates value, and therefore will scale on its own merit. This silent surety on the part of governments as well as the clearly defined, immediately available benefits will give individual’s the boost they need to rise to the occasion - and raise their country with them.

The best part? People-driven transformation is lasting - across the changing tides of policy and procurements.

Question: Will DPI deepen the digital divide?

Short Answer: Nope. DPI is not the same as digitisation. Well designed DPI caters equally to people with and without connectivity, and with and without smartphones.

Long Answer: Often the word ‘digital’ of the term ‘digital public infrastructure’ is misconstrued to mean that it always requires internet connectivity and access to smartphones and thus, leaves behind the people who don’t have access to such technology, connectivity, or devices.

DPI is often, mistakenly, used interchangeably with digitisation (the process of taking paper-based processes online). The DPI approach is sometimes met with scepticism from countries who may have many barriers to cross before a fully-online world becomes a reality for them. This fear - that DPI will not be able to bridge the digital divide - remains one of the most unfortunate misunderstandings of our time!

The core mission of solutions built through the DPI approach is to reach the last mile population where they are and integrate them into the formal society in a variety of ways. It is fully cognisant of the fact that countries are inherently diverse - there will be people who are fully privileged, and those who lack access to basic resources, education and abilities in every society. For services to truly scale inclusively, one has to reach people on both ends of the spectrum and cater to a diverse population via multi-modal access points and solution-agnostic protocols that are not hardwired to any specific format in which to access services..The availability of multiple options is what ultimately drives inclusion across diverse populations, and ultimately, DPI aims to elevate underserved communities to a level economic playing field through equal access, despite their current resources.

For example, when we speak about a Digital ID, they are not necessarily dependent on smart cards, or online authentication modes only.

Similarly, when we speak about interoperable digital payments as DPI, they are not limited to those with access to digital devices:

Well designed DPI are suit diverse audiences with unique needs. It is important to note that the same DPI rails - using standard protocols - can cater to all sets of people and newer innovations can simply be added on top without needing to extensively change the underlying codes or protocols or building separate solutions for rural contexts or vulnerable populations (which tend to be under-maintained).

Solutions built through the DPI approach are required to be:

1. Minimalist

2. Modular

3. Reusable

4. Federated

5. Secure

This allows for inclusive innovation with diverse access methods to be easily built on top of the foundational rails.

Building a use cases layer on top of any foundational/ functional ID system is crucial in unlocking service delivery. ID should be considered an infrastructure to provide citizens seamless access to services. An ID system is only as powerful as the use cases it can unlock. This is also how countries can encourage enrollment and ensure that their ID system is “sticky”. The layers built on an identity system outlined below can make an existing ID system operate as digital public infrastructure in an economy, and can all help increase the enrollment/adoption and usage of an identity.

Overview

Authenticating a user is most primitive action in any service delivery. Assuming user's registered photo is available in digital form and is easily verifiable, opening up face authentication on mobile phone app(s) creates non linear scale in providing services in an inclusive way.

Assumptions

1. Country or any department offers a digitally signed artefact i.e JSON/XML document as file or in QR code format with foundational/functional ID or ID alias, Photo and any other minimal information requried for validation to deliver a service.

2. Access to this digitally signed artefact can be through a digitial copy shared or securely cached on a mobile device, scanned through QR code using a printed or physically issued card.

Challenges

Following are few common challenges in any given country / context that is the primary cause for user exclusion who may other wise can be easily reached to deliver services:

1. Access : Not all users are digitally savy to own and/or operate a mobile phone.

2. Reach : Network connectivity or coverage is a universal challenge to avial online services.

3. Digital Literacy : Many users lack digital financial literacy e.g., handling of PIN/OTPs.

4. Choice : Users trust known neighbourhood agents and choice to pick the service touch points/agents is key to build trust / inclusion.

5. Automation : Manual steps/processes cause delays, middlemen

Approach

Following are few key capabilities to consider to address above challenges:

1. Mobile First : Mobile first approach is to have service delivery enabled using mobile devices like phones, tablets, laptops. Ideally build once and deployed across operating system platforms is encouraged to keep the IT systems lean.

2. Online/Offline : Mobile device based delivery enables local secure storage to strategise processes for offline delivery when online services are not reachable due to network connectivity/coverage. System processes can be dictated to grant device level online/offline policies based on local context.

3. Smart Synchronization: Offline service delivery requires required master, reference and recent transactional data available for taking minimum required business validations.

4. Self/Assisted : Business processes to be aligned for self and assisted use case scenarios.

5. Local Face Auth : Face authentication with liveness checks on the edge device as reusable software library/module across various department apps. This can act digital rail infrastructure component.

6. Device Registration : All mobile devices enabled to provide self or asssisted services can be registered to manage granual level of controls to deliver services in secure and trusted environments.

7. Assisted Operators: All assisted operators enabled to provide assisted services can be trained and registered to deliver remote services.

Risk Mitigation

1. Face authentication models should be well tested to ensure seamless user experience to address inclusion. The solution should work in conditions like low device technical specifications, lighting conditions, ease use, local language support, integration with business application flows etc.,

2. Face authentication models should be integrated with face liveness detection process as well.

3. Digital exception management should integrated into the workflows thought reason codes. Scenarios where face liveness / match, backend service related errors to be handled through a well thought through exception management process.

4. Continuous improvements to both technical and business processs should be considered by analysing the telemetry data from the devices.

Summary

Face Autentication using a mobile device opens up an oppurtunity for governments to serve large number of excluded population with ease.

Attributions

In the previous section, we discussed the concept of a digital ID. It’s imperative to reiterate that the core attributes of a digital ID are that it is both machine and human-readable, verifiable, and digitally signed to ensure it is tamper-proof.

Verifying the identity of a user (also called authentication) before any transaction is a fundamental function in any economy, and is the key feature that can upgrade any existing ID system to help it operate as digital public infrastructure. Everyday activities like opening a bank account, availing a government service, purchasing a new mobile sim card, etc. necessitate a layer of trust and traceability. Traditionally, verification has been done by producing physical copies of any issued govt. document and acceptance of the document was left to the individual/ entity providing service. This is a low-trust, time-consuming, and expensive process.

The most powerful application/ addition of any identifier is to use it for electronic authentication across a digital economy by any public or private player. This can be done by building a digital auth layer on top of the ID system, enabling people to prove their identities online or offline.

ID authentication is the process by which an ID number or a tokenized version of the ID along with one type of authentication factor is used to verify a citizen's identity. The ID system can be queried and it will provide a Yes/ No response to the question - “Are you who you claim to be?”

There are a few key modes of authentication:

1. Demographic; which verifies a person’s name, address, date of birth, or other information fields

2. Biometric; which verifies a person’s fingerprints or iris

4. One-time password; where a single-use password is sent to a registered mobile number or email address

ID Authentication provides an API-based authentication mechanism for entities to validate individuals. In each of the above cases, the ID number and one piece of information are submitted to the ID authority’s database for its verification and the ID authority verifies the correctness of the details submitted, or the lack thereof.

Additionally, offline local ID authentication can happen if the ID authority offers a digitally signed artefact i.e. JSON/XML document (as a file or in QR code format) with foundational/functional ID or ID alias, photo, and any other minimal information required for validation to deliver a service.

Depending on the strength of verification required, two-factor authentication can also be considered. In all these cases, the citizen is assumed to have consented to the verification process.

Authentication should be thought through three key dimensions :

• Proof: What's the authentication intended to prove? Is it proof of document, proof of identity, proof of presence or proof of existence.

• Self and assisted channels

• Offline and online modes

Building this authentication layer on ID and opening it to licensed private/ public service providers is a huge step towards innovation as well as inclusion. Online, low-cost, and almost instant authentication will power the rise of an entirely new class of applications and increase trust in the digital economy.

Probable challenges & workarounds:

1. Hard Infrastructure, connectivity & coverage: Procurement of any specialized hardware for authentication can become prohibitively expensive at a national scale. This and accessibility constraints can impede the delivery of services in rural, remote areas.

• A choice that any government can make in this regard is to allow private players to become e-auth service providers after adequate training & certification. Opting to publish all the hardware standards brings market forces into play, resulting in competitive prices for everyone.

• Offering offline mobile-first authentication can eliminate the need for smaller scale verifiers to procure expensive hardware such as smartcard readers or biometric scanners.

1. Inclusion & scale: Not all segments of the population can utilise biometrics due to factors such as age or disability. Additionally, not everyone possesses the digital proficiency to own or use a mobile phone. Overlooking these realities risks excluding these vulnerable groups from accessing vital services.

• Enabling multimodal (via OTP, QR codes, biometrics and face) & offline authentication will solve for inclusion at scale - increasing the coverage of services.

1. Data security & privacy: Concerns about the security of data and possible misuse of the shared information.

• It’s on the government to balance innovation while ensuring that no one has uncontrolled access to private data. The concerned government departments can choose to identify authorised service providers after licensing and testing. These should be mandated to maintain logs of data accessed, which can then be scrutinised by the regulators.

The digital ID serves as a key to a broad spectrum of services, encompassing financial inclusion, social protection, and efficient benefits delivery. Seamless, inexpensive user verification can power multiple use cases within the govt. and beyond. For example,

• Authentication for benefits delivery like -

- G2P payments

- Health insurance coverage

- Enrollment in scholarship programs

- Subsidies distribution

• Voter registration

• Biometric attendance for govt. Officials or schemes

• Authentication for data fetches (such as credentials)

• Face authentication for liveness

References:

Context

QR codes are omnipresent and act as a bridge to connect the physical world with digital. QR codes also help users with minimal or no digital literacy to safely navigate performing digital transactions such as payments, enrolling into social programs, proving credentials (such as driving /university/ employment credentials), sharing resources (like photos/documents/contacts), tracking e-commerce orders and shipments, etc.,

This note calls out design, implementation best practices in identity / credential domain for offline use of QR. These principles hold true for other domains as well.

Design Considerations

1. Messages in QR code must be compacted to ensure low / medium priced mobile phones can easily scan and decode the text. Representing the entire payload (id/credential data, digital signature and corresponding public key to verify) in ~2K characters is key to QR code design.

2. QR code must be capable of digitally verifying the authenticity of the ID credential.

3. QR code should allow 1:1 face matching of the photo ID / credential with live person using one or more face matching algorithms. This enables inclusion of users with no devices or minimal digital literacy to prove identity and to access digital services with high trust, low cost and low friction (self/assisted, any time, any where use).

Recommendations

Based on the above design considerations, CDPI recommends the following design and implementation guidelines:

1. QR codes must be versioned. Version number helps refer to the right QR schema registry for decoding. This allows evolvability of the QR.

2. Custom format must support scalability built-in for multiple libraries to decode the QR. Encoding should allow optionality of certain attributes, and capability to add new attributes that a country would like to incorporate into the QR code.

3. To digitally verify the authenticity of QR:

   1. Design should support more than one cryptographic option for digital signing to enable reasonable backward and future proofing new techniques.

   2. Design should allow key rotation and assume there will be valid QR codes with different key pairs issued at different time.

   3. Make public signing keys available as a registry. All known public signing keys should be easily referenced using a key ID. This helps in reducing the QR code size too.

4. To protect sensitive attributes such as permanent IDs, phone number, email ID, etc., consider designing encryption or one way hashing through user controlled key as salt. Additionally, consider Secure QR format over regular QRs.

5. Raw compressed face photo in the QR should work with at least 3 different face matching algorithm's threshold scores (FRR and FAR) 1 that is acceptable and meet in overall inclusion strategies. Face image can also be represented as template/embedding and help in reducing the photo size to few hundred bytes (~500).

6. End to end testing should be carried out in multiple phases to ensure all functional and non-functional objectives of the design / specifications are achieved:

   1. Phase-1: Lab testing with synthesised data sets to validate the design, specs and code. Testing can be through APIs and not necessarily people involved. Sample size ~10 qr messages, ~5 devices.

   2. Phase-2: Controlled team testing with actual people in the office or nearby location. Sample size ~100 qr messages, ~10 devices, ~1 location.

   3. Phase-3: Integrating the solution with actual business application/workflow and controlled field testing. Sample size ~1000 people, ~100 devices and ~10 locations.

   4. Phase-4: Rolling out the above integrated business use case solution within a region (or country wide) to evaluate end to end solution offering (including 1:1 face matching). Additionally, test the solution against multiple use cases to get feedback and improve specs/design/solution offering.

   5. Phase-5: Formal 1.0 release of specs/solution for the country/region. Propose specifications with regional and/or global standardisation bodies.

References

In the 21st century, data operates as digital capital. The ability to create value from data is especially crucial to those individuals, entities, and societies who may be data-rich even before they are financially rich or healthy.

A DPI approach to data sharing can include the following possible use cases:

1. The ability to generate verifiable credentials for key certificates/claims in a digital society and share asynchronously with any requestor (eg. proof of education; proof of business registration; proof of work experience, proof of vaccination, etc.)

2. The ability to share personal data in real-time in a secure, consented manner bilaterally with a party offering me a service based on the data (eg a health diagnosis, a loan, a recommendation, etc.)

3. The ability for a society to generate open anonymised datasets to enable research or trends assessments across various sectors

Additionally, the open anonymised datasets can be used to train and publish open AI/ML models that can be used to better enable access to services based on data, e.g. real time language translation models; financial underwriting models; etc.

Most governments offer a variety of services to their citizens. It is costly and redundant to have each service provider maintain a separate list of authenticated users and their passwords.

Single sign-on is an authentication scheme that can be integrated into multiple applications to allows a user to access services. It enables an user to log in with a single ID to any of several related, yet independent, software systems.

Having a digital ID-based SSO will drastically simplify the service delivery while reducing the dependence on 3rd party SSO providers. End users can identify themselves in order to avail of online services and also share their profile information.

ID-based SSO can be connected to any ID that provides a mechanism to authenticate the users.

How does this work?

1. The user visits the service provider and chooses to login with ID-based SSO option

2. The user has to authenticate their identity via any of the provided modes.

3. Upon authentication, the user’s explicit consent is sought to share profile data fields.

4. The service provider can authenticate a user’s identity against data stored on any identity system via SSO.

Any ID-based SSO should provide multiple modes of user authentication including OTP-based, biometrics or even wallet-linked authentication.

Benefits of SSO:

1. By providing as a secure, efficient log-in mechanism, ID-based SSO increases the ease of doing business for individuals and businesses, Along with increasing digital economic activity, this also presents a potential revenue stream for the governemnt.

2. This can be used for consented data sharing of ID profile fields or for eKYC needs of different applications. An application’s authentication request can also ask for details needed for profile setup or eKYC compliance, which can be shared upon explicitly receiving user consent.

References:

1. https://docs.mosip.io/1.2.0/integrations/e-signet

Every identity system has a few data fields like biometrics, photograph, demographic details, email id/ mobile number, which in combination identifies each individual uniquely . For numerous applications, it is essential to authenticate the user and obtain their profile details from a trusted source.

KYC involves establishing and verifying a person’s/ an organization’s identity to assess and monitor customer risk. KYC requirements in most countries mandate that citizens provide proof of their identity and address. Physically producing and verifying these documents is expensive at scale because of the high transactional costs involved, large TATs, and low trust in the system. As a result, countries reach a point where operational costs around identity verification are a barrier to getting services to the poor and disadvantaged.

This creates a need for a process that’s not only digital, and instant but also fool-proof and non-repudiable.

In ID-based eKYC, identity is verified electronically after which the service provider can access the profile details of your ID from the ID authority database. It’s a value addition on top of ID-auth and allows an individual to share these profile fields to any system.

How does eKYC work?

1. The user’s identity is verified using ID number and biometric data/ OTP from ID DB via a service provider (refer to e-Auth)

2. Upon authorisation, the user authorizes the ID authority to release the minimum required demographic information and photograph (KYC packet) to the requesting entity via a standard API.

ID-based e-KYC can be built as an independent service that can be seeded with data for authentication by any ID system. The ID based e-KYC is an extension of auth; however, a key distinction is that any requesting entity can receive and store identity profile data.

Probable challenges & workarounds:

1. Infrastructure, connectivity & coverage: Procurement of any specialized hardware for authentication can become prohibitively expensive at a national scale. This and accessibility constraints can impede the delivery of services in rural, remote areas.

• A choice that any government can make in this regard is to allow private players to become e-auth service providers after adequate training & certification. Opting to publish all the hardware standards brings market forces into play, resulting in competitive prices for everyone.

• Offline mobile-first authentication can will eliminate the need to procure expensive hardware.

1. Data security & privacy: Concerns about the security of data and possible misuse of the shared information.

• It’s on the government to balance innovation while ensuring that no one has uncontrolled access to private data. The concerned government departments can choose to identify authorized service providers after licensing and testing. These should be mandated to maintain logs of data access, which can then be scrutinized by the regulators.

• A user should also have the ability to revoke access to their KYC data by any service provider or entity at any time.

Use cases:

• Financial inclusion via bank account opening

• KYC for purchase for mobile sims

• Securities account opening

• Enrollment in govt. schemes

References:

1. https://docs.mosip.io/1.2.0/modules/id-authentication-services

2. https://govstack.gitbook.io/bb-identity/3-terminology

3. Rebooting India - Nandan Nilekani & Viral Shah

Context

Government's primary aim is to reach out to specific target user base to easily identify a user and deliver govt services - e.g. medical care, pensions, collect taxes, etc., Every country can relate to existence of at-least one of the below identity systems:

1. National Registration Cards (NRC)

2. Regional Govts Identity Cards

3. Registrations done with one or more biometric modalities (finger, iris, face, voice, etc.,) but may or may not have used for deduplication / uniqueness checks

4. Foundational identities - Civil Birth/Death, National Id, etc.,

5. Purpose driven functional identities - Voting, Driving, Farming, Taxation, Professional Practice (Doctor, Lawyer, Teacher, etc.,)

6. Foundational/Functional IDs restricted to certain category of users - e.g., All Citizens, Citizens above x years, Residents, Refugees, etc.,

In most of the countries foundational or functional IDs are issued as:

1. Simple paper optionally with a photo and/or hologram sticker

2. Laminate the paper based ID

3. PVC card with one more security features like:

   1. Photo

   2. Hologram sticker

   3. Micro text

   4. Ghost image

   5. ID authority logo

   6. Guilloche patterns

   7. Issue/expiry dates printed

   8. Barcode / QR Code / Magnetic Strip / RFID / Smart Chip

   9. etc.,

While the above IDs are enrolled and issued with multiple levels of physical verification, the IDs issued within a jurisdiction do have a good level of trust and acceptance within the country to deliver govt services. However, governments are challenged to accept foundational or functional IDs for various reasons:

1. Detecting genuine vs fraudulent ID cards;

2. Trusting scanned QR code content;

3. Procuring large number of vendor specific card readers (ID cards with RFID, smart chip);

4. Reissuing expired ID cards;

5. Trusting IDs outside of the issuing authority jurisdiction / network (service points, systems);

In these challenging scenarios governments are trying to address globally accepted Sustainable Development Goals (SDGs) by adopting digital transformation programs. Governments and Development Agencies are investing large sums of money to digitise business processes by building portals, mobile apps, and platforms to reach the target user base while NOT able to IDENTIFY & AUTHENTICATE the user with 100% TRUST.

DIGITISING AN EXISTING ID INTO A DIGITAL ID CAN OPEN UP NON LINEAR OPPORTUNITIES FOR GOVTS TO DRIVE DIGITAL INCLUSION VIA UNIVERSALLY ACCEPTED, TRUSTED DIGITAL IDs.

What is a Digital ID?

Any foundational or functional ID that supports below properties is considered a Digital ID:

1. Human/System Readable - Digital ID MUST be presented in a format that can be read by a human and systems. Key user identity attributes MUST be made available in QR Code format for systems to easily scan and read.

2. Verifiable - QR Code component of ID MUST be digitally signed by the issuing authority and verification of digital signature to prove non-repudiability be made possible. Human verifying a QR code can be made possible using QR Code reader apps/sdk's.

3. Online/Offline Accessible - Digital ID MUST be accessible through Online APIs. Digital ID MUST also be made available for offline use through digital wallets or by digitally signed QR codes.

4. Online/Offline Authentication - Digital ID MUST be able to authenticate the user both in online and offline modes. In Offline mode authentication service points are able to verify users in low or no network coverage regions with trust.

5. Consented Use - Use of Digital ID SHALL enable mechanisms to implement consents from the ID holder during authentication or data access or while other uses of ID.

6. Privacy Protecting - Digital ID SHALL enable option to mask ID for usage scenarios where full ID is not required and ensure necessary consented authorisation for data access.

7. Self / Assisted Use Cases - Digital ID SHALL enable self & assisted use cases to access, verify and authenticate the user with consents. Use of authorised operators helps to reach digitally illiterate users and helps in inclusion via open APIs with necessary authorisation by the ID holder.

8. Enable Full/Selective KYC Disclosure - Digital ID SHALL enable option to release full or selective Know Your Customer (KYC) attributes for downstream use of ID.

9. Unique ID - Digital ID MAY be deduplicated against biometric or demographic data to ensure ONLY unique IDs are issued. Uniqueness of an ID is NOT a necessary requirement. Many use cases do not require to identify and authenticate an unique user. Identifying and easily/securely authenticating a user is sufficient.

10. Laws/Regulations - Digital ID MAY be governed by local laws/regulations to ensure equitable access to ecosystem participants across sectors to reduce friction and costs. Laws/regulations ensures acceptance of DIGITAL ID called out though above properties to create a multiplier effect as a foundational Digital Public Infrastructure.

Why is Digital ID important?

Many govt programs do not require a unique ID to deliver services. Very few services may actually require a unique id. Use of Digital IDs shall allow policy makers to reduce friction/cost and to allow integration between systems.

Digital ID use shall enable policy makers to integrate with other jurisdiction functional id’s while finding duplicates through trusted demographic data techniques is a continuous improvement process to remove ghost beneficiaries.

Digital IDs made available from existing functional ID systems can eventually link to deduplicated foundational IDs i.e when a country adopts such a deduplicated issuance platform.

While a biometric deduplicated ID system is considered a fool proof ID issuance platform, Governments need not wait for such an ideal scenario to identify a user with TRUST both in physical and digital worlds.

How to convert an existing ID to a Digital ID

Governments can consider below indicative suggestions as an inspiration to to convert physical IDs to Digital IDs:

1. Govt should enable issuance and use of PKI certificates as per globally accepted practices within the country.

2. ID authority that owns and maintains a physical registry can consider digitising the data as is into a database.

3. Any additional clean up to improve the quality of the data formats should be taken up during this phase.

   1. Latest good quality photo and/or verified mobile number should be part of the ID database/registry

   2. These two key ID attributes shall open up verification and authentication capabilities.

4. ID authority should procure PKI certificates to issue Online Digital IDs through Auth/eKYC APIs and Offline Digital IDs through mobile wallet / eLocker apps.

5. ID authority should enable govt and private ecosystem players to access Digital ID through api’s, self/assisted use, acceptance of digitally signed docs, cyber & information security laws, user privacy laws and related policies.

Merging multiple different ID cards into one card is not necessary

Merging many different identity cards is not necessary, and in fact, various countries retain a combination of functional IDs (such as a driver's license, farmers certificate etc.) and foundational IDs.

A foundational ID is able to scale to become a national ID only when it is minimalist (captures the very basic 5-7 data points on an individual such as name, gender, date of birth, address, and some authentication capabilities) and delivers value through reusability (by e-auth and e-kyc).

e-Authentication is a feature that can submit a yes/no response when asked, and e-KYC is a feature that can submit foundational profile fields in addition to authentication. The single-sign-on capability allows an individual to log-on to any government or private portal on the basis of their government issued iD (similar to using a Google account to log on to a website).

For functional IDs, building an auth feature would be most useful since other departments can verify the identity of the concerned individual before issuing a service to them (such as a social benefits department authenticates if a person is a farmer before transferring money to them).

For national IDs (such as minor ID, passport, Non-resident ID), e-auth or SSO may be built.

And for the national foundational ID, either of the three features may be built for individuals to utilise.

These capabilities can be built on any current identity in the country (depending on the nature of the ID) within a matter of weeks and leveraged by individuals and institutions to access trusted information based on the individual's consent to provide more efficient access to services such as opening a bank account or availing benefits through a government portal.

IMPORTANT NOTES:

1. EACH COUNTRY MUST HAVE THEIR OWN STRATEGY TO MAKE FOUNDATIONAL & FUNCTIONAL IDS AVAILABLE AS DIGITAL IDs.

2. THIS DIGITAL ID CONCEPT FOR A PERSON CAN BE EXTENDED TO ORGANISATIONS, ENTITIES AND THINGS.

3. HAVING A DIGITAL ID IS MUST HAVE DIGITAL PUBLIC INFRASTRUCTURE (DPI) FOR ANY DIGITAL TRANSFORMATION JOURNEY!

Attributions

Any interactions in a digital economy create huge swathes of data that if shared with the right stakeholder, can empower the owner to access a wide range of services. Globally, a lot of emphasis is placed on “data protection” which is ensuring that the individual’s data is protected from unauthorised access. It’s useful to think of data as a modern day currency that can be used to unlock services. This framing brings about a shift from the model of data protection to data protection & empowerment where the user is in control of their data (both privately & publicity held) and can freely share it. Opening up access to personal data, reference data sets (data used to define and classify other data), anonymised and aggregated data sets, training data and models also falls under the bucket of data empowerment.

Personal data sharing can take the form of verifiable credentials sharing or sharing of granular data with the requestor.

Broadly, we can identify three types of consented data sharing:

1. Verifiable credentials using e-wallets

2. System-to-system data sharing

3. Consent-led data sharing using a network

1. Verifiable credentials: A verifiable credential is a robust instrument of trust which is digitally signed, machine-readable and intended to serve as proof to presenters. Any certificate/ credential can be turned into and presented as a verifiable credential (for eg; Vaccination certificate, professional license, education records etc.) Sharing the verifiable credentials to any of the requesters through a digital wallet or any other means is a form of data sharing. It is also recommended that data principal’s consent be captured in this process. Common examples in healthcare are; sharing vaccination certificates, sharing of doctors’ professional certifications, etc.

2. System-to-system data sharing: In many cases, there’s a need to share per-collected/ existing data internally (within departments that come under a single umbrella like the government) or within a group of trusted entities. In this case, a system-to-system data-sharing process can be put in place without involving the data principal. Data sharing open APIs and an authorization mechanism to verify the requestor’s permission will power this. This architecture should only be used in a high-trust environment. Common examples are the sharing of patients' data between two govt. programs etc. (It is strongly recommended to procure the data principal’s consent before the data sharing and to notify the data principal after the transfer.)

3. Consent-led data sharing in a network: In this model, a network facilitates the exchange of data from the data providers to data users via the data principal (user). There's no centralised store of data and data flows real-time based on a request that carries the user's consent as well. The user is wholly in control in this framework. Three powerful technical building blocks can drive user centric, consented, real time data sharing, namely data sharing APIs, sector specific data schema and consent standard.

Cross-border data sharing

Cross border flows are simplest with user-led methods such as credentials, which don’t require issuing parties to have bilateral or multilateral agreements in place with every possible international verifier of a credential. Instead, any potential verifying entity of the credential who wishes to access the data can locally verify the digital signature to access the personal data presented by the user. The verifying entity should ensure to have access to (and cache with ttl - time to live settings) trust registries namely - global issuer list, corresponding verification keys & revocation list and credential data schema to accept credentials with higher trust and convenience to the presenter.

System-to-system data sharing in cross border use cases can require a slightly higher level of coordination between government departments, the establishment of international consent managers, supporting legal or regulatory frameworks, security clearances (for opening up of API ports) as well as interoperability of technical systems in order to be successful.

Federated anonymised data sets can be utilised for cross-border research and developmental initiatives as well through proper contextualisation of the data. Please refer here for additional design choices to enable and access federated anonymised data sets.

As systems become more digitized, solving incompatibilities between data in different systems becomes expensive and time-consuming. A key precursor to interoperability is a shared understanding of the meaning of data used in communication. Data standards refer to the guidelines that dictate how data should be documented and recorded. These standards are essential for the effective exchange, sharing, and comprehension of data, as they ensure both the syntax (structure) and the semantics (meaning) of the data are uniform. By establishing clear definitions and expected formats for data, data standards facilitate the creation, sharing, and integration of data. They also play a crucial role in eliminating uncertainties and inconsistencies in data usage.

Some examples of data standards are ISO 10962 Classification of Financial Instruments, ICD 10, LOINC in healthcare, FI information standards in Account Aggregator, and many more!

Many of these standards are extendable implying countries can adopt some of these global standards as a base and contextualize it to suit their local requirements.

Any country on the journey of adopting a national standard can use adaptors (to solve incompatibility issues in the interim) to hasten the process. As harmonizing data standards used by all institutions is a behemoth task, multiple data standards can co-exist as long as they are self-identifying.

Three key components make up this DPI category:

1. Digital Signatures or PKI: To ensure a document/certificate/data packet hasn't been tampered with, a nation needs to generate the capability to affix a verifiable digital signature.

2. eSignatures: The ability of an individual or entity to electronically sign a document digitally (via mobile) to indicate agreement

3. Granular Consent: The ability of an individual to indicate their consent to share data for a specific purpose and time period with an indicated third party, and generate an auditable and digitally signed consent artefact to indicate that intent.

Background

Governments interact with the individuals in their country for various purposes - to offer jobs, subsidies, benefits, contracts and more. Private entities such as banks, businesses and educational institutions also interact with individuals to deem eligibility and validity for a number of programs.

The foundation for any of these processes is to establish the attributes of the individual by verifying documents to determine their eligibility for services or benefits.

In the current scenario, both sectors (public and private) spend considerable amounts of effort into verifying the authenticity of the individual’s data, with no guarantee of success. Mistakes can be costly - with large sums of money and opportunities not reaching the intended people. They can also be dangerous - with unverified individual’s gaining access to sensitive systems and processes.

Digitally verifiable credentials, a simple, marginal improvement to existing systems, built using a Digital Public Infrastructure approach can solve this problem at scale.

What are verifiable credentials?

Any issuing authority (whether they are issuing national identity, school certifications, income certificates, recommendation letters, driving licences, tax identity, etc) can make their certificates tamper proof while retaining full autonomy over it.

Paper Certificates can contain a digitally signed online / offline QR code that connects the paper based document to an official server and fetches the original certificate for verification. The soft copies of the certificates can be digitally signed to add an extra layer of security guaranteeing authenticity.

In this method, no centralisation is required. It allows various departments to retain control over their certificates, and prevents single storage databases that inadvertently become the target of cyber attacks as well as leakages.

How does it work?

The application programming interfaces (APIs) of different issuing authorities are opened up to create a real time data fetch between systems. Data is fetched (but not stored) based on API calls made from one system to another asking to validate a particular piece of data based on the individual’s consent. Any data issuing authority and any data-consuming authority can link to the same network by connecting their APIs and clearing their own verification as per the guidelines issued by the country.

Data should only be verified based on an individual’s consent. As with all DPIs, the person should be at the centre of the infrastructure.

An individual can specify the data he wants verified, the party he wants to share it with, and the period of time he wants to share it for. The consent is granular, purpose specific (eg for a loan or benefit), simple to understand, and revocable.

There can be three broad modes of data sharing:

1. Consent and data are shared at the same time through the same platform: In this model, the interface itself (wallets or e-lockers) obtain user consent through their platform and share the data immediately. For example, digilocker in India

a) Wallets: In digital wallets, users can provide their consent to fetch their digitally signed documents from various entities. These documents are stored on the user’s dashboard and can be shown to anyone. They empower the individual by giving them control over all their verified credentials.

b) e-Lockers: In this, the documents are not stored on any dashboard. When the user provides consent, these documents can be fetched from the provider and displayed to the user or the data-consumer he provides his consent to. These eLockers are managed by one or more entities in the country and allow federation of verifiable credentials.

1. Consent and data are shared separately and managed through different entities: In this model, the consent is managed through a third-party intermediary known as a consent manager. These entities obtain user consent as per the consent artefact specified and communicate that to data-providers who then separately share that data to the data-consumers. For example, the Account Aggregator ecosystem in India.

2. Consent is managed through the data provider: In this model, data is shared between two entities such as two government departments without the individual being directly involved (though ultimately for the individual’s benefit). Consent is provided by the data-provider itself at the time of sharing the data.

There are many examples of this DPI:

Benefits:

Opening up APIs also allows for multiple market players to build direct and indirect products over it. For example, various user-facing applications can be developed, focusing on different target groups, languages, purposes etc. that allow people to seamlessly provide consent (according to a consent artefact specified) to have their data fetched and shared with third parties.

Verifiable credentials empower individuals and institutions alike; they enable people to own their data and allow institutions to focus on delivering last-mile services on the basis of that data.

It is only when we can easily know about each individual that we can effectively build for each individual.

Summary of the DPI approach to verifiable credentials:

Additional Resources on Verifiable Credentials:

Why is an e-locker essential?

Imagine a person, A, who needs to apply for a government job. She travels to a metropolitan city Y to look for jobs while her documents are still safely back home in town X. In a world without an e-locker the entire process from securing documents to securing a job could involve the following:

1. She will have to locate the original documents right from birth certificate to identity proof to college marksheets. To do so, she will either have to travel back herself (spending essential time and money) or ask someone to send them to her (risking loss or damage through courier).

2. These documents may have been misplaced over the years due to misfortune or carelessness. The process of reapplying for them could take months. If she tries to apply through an agent to expedite the process, it can open the gates to corruption and misuse of her documentation.

3. Once the documents have been secured and submitted, the onus will now be on the agency to verify all information - not just hers but for the thousands of applications who have applied to fill in the few vacancies. It will be a massive undertaking of labour, money and time involving paper storage, manual verification and audits. The chances of fraud through misuse of another’s documents or false modification of their own will also always be high.

Multiple organisations face similar challenges for the dispersal of essential services and opportunities to the public. The process of verification - of ensuring that someone is who they say they are is extensive and exhaustive; at least it used to be … before an e-locker.

What is an e-locker?

An e-locker is an online, verifiable, digital locker App where various government issued and approved documents are stored. An e-locker provides the following services:

1. Anytime Anywhere Access: to all documents in a secure, tamper-evident way (through digital signatures and time stamps). Any agency (government, private or public) can apply to issue or receive documents through an e-locker. They have to be approved by the government to be issuers, and by the individuals to be receivers of their documents.

2. Authentication: of all documents, pre-verified, at par with physical original copies. The e-locker can be built on top of a national ID that can uniquely identify every individual to connect them with their data using multifactor authentication based log-in, or allow log in based on a mobile number or other verifiable identifier

3. Data Exchange: granular consent (for a specific time period and purpose) based exchange of documents in machine readable formats for low cost software evaluations of data (such as those offered by a lending algorithm or shortlisting people for jobs)

An e-locker is based on the following principles:

1. Decentralised control, consent-first approach - it fetches the data from a variety of organisations based on real time user consent and the unique document or individual ID number instead of storing it in a centralised database.

2. High-trust, low risk - it can use the highest government level security systems such as multi factor authentication, 2048 bit RSA SSL encryption, ISO 27001 certified data housing, security audits and more, to build a layer of trust between all parties and eliminate fraud. The documents are also protected and guaranteed under the Indian IT Act.

3. Paperless power sharing - it steers the cumbersome, paper and labour heavy, governance systems to a digital era and allows equitable distribution of power among individuals from all income, educational and societal levels. It is able to do so by providing multiple options for organisations to integrate and for people to come onboard the system depending on their own technical capabilities. The goal of DPI is to decrease the digital divide by connecting with them at their level while raising them up to a common standard.

4. Many apps, many certificates - Well designed eLockers should have open APIs for issuers of documents and requestors of documents to power multiple apps to access the credentials based on an open network approach

In a world with an e-locker, A would have all her documents stored on her smartphone for easy access and sharing. Within a day, she could apply, be verified, selected, and employed by any agency.

Another urgent use-case for an e-locker was storing and verifying an individual's vaccination certificates during the Covid-19 pandemic. The use of e-lockers during this period also demonstrated how easy it would be to store all certifications and documents right from business licence/ registration, to proof of academic history and employment history, to land ownership, individual identity and more.

How does implementing an e-locker benefit a country?

By creating a uniform system for retrieval of documents (while keeping storage of data still decentralised) through an e-locker, a government can:

1. Stimulate the country’s digital economy across sectors (financial institutions, employers, healthcare providers, social sector workers) by providing verification of individuals’ documents. Large scale adoptions of DPI such as e-lockers also builds public trust in technologies and triggers new innovation in trusted digital services.

2. Build inclusive systems and structures by eliminating the time, effort, cost gaps that often dominate the availment of opportunities such disbursement of health, financial and social services and leave the last mile population behind

3. Reduce corruption and exploitation by building high-trust systems for the vulnerable sections of society who lack the knowledge and tech-savviness to use private, paid providers (who may not be recognised under the country’s IT Act anyway)

4. Make it convenient for multiple local, provincial, state, or national departments to provide digitally signed quality digital documents It allows any department to issue digitally signed machine readable credentials without purchasing their own signing infrastructure while still retaining control over the documents they issue.

5. Allow organic and asynchronous digital growth in a society by letting different organisations integrate with an e-locker at their own pace..

In India, an MSME portal, Udyam, was able to integrate and issue their existing certifications for small businesses through e-lockers in just three weeks!

How does an e-locker work? Tech overview of the system

1. Type of DPI: Data Sharing & Models

2. There are 3 parties to any interaction: the issuer of documentation, the individual and the requester of documentation.

3. Issuers upload groups of verified documents in various repositories, and individuals can upload their own documents self-attested in personal e-lockers. Requesters can ask for information from either place.

4. All information can communicate with each other and pass freely in the system because it complies with DLTS specifications, has unique document URIs and authentication using strongly verifiable identity

5. When the requester asks for a particular document, it is passed on to the individual who provides a URI of either a repository or their e-locker. Requester uses DLTS Gateway API to access the document based on the URI. This API call may need one more step of consent verification from the individual.

6. The gateway provider will map the URI to an actual URL to draw out the actual documentation and send it back to the requester. Authentication and time-stamping will be automatically conducted both ways (from gateway to repository and back). Anonymised audit logs will be stored by the gateway and the repository provider. This completes the process.

7. The e-locker has 2 published sets of open APIs - one for the requestor and one for the issuer.

8. You can also open APIs in any e-locker app so that any application can fetch the credentials in the future (not just the official e-locker application) as long as you have verifiable identity that used to log in.

Background

Publicly available anonymized datasets are collections of data that have undergone a process of data anonymization, which preserves the analytical and research value of data while maintaining the anonymity of any data subjects. The purpose of this process is to protect individuals' privacy by removing personally identifiable information (PII), such as names, addresses, and social security numbers, while still making available data containing important insights for policy, administrative, research or trends assessments across various sectors. Non-personal data includes the above as well as data that had no personal information to begin with (such as public GIS location, regional/national socio-economic indicators, weather or aggregated tax collections. ).

These datasets can be made freely available to the public to encourage innovation, promote transparency, or assist in scientific research. For example, public anonymized datasets can be useful in training machine learning (ML) models, analysing aggregated health data to understand disease patterns, devising informed care plans, and designing clinical trials for drug development. They facilitate algorithm training without privacy breaches, inform healthcare strategies, optimise trial protocols, and expedite drug discovery while upholding privacy and ethical standards.

To ensure success at scale, it is important to note that a centralised approach to aggregated datasets may be difficult to scale since every entity will be required to upload their datasets onto a single platform and they may be hesitant to part with their data. Even if they do share their data, ensuring it is regularly updated and synced to the main system would be an uphill task. A simpler approach is to create an open network policy for anonymised data sharing. Entities can engage the help of any technology provider and join the network to share their data under their own brand. This would give them recognition and control over their own datasets and make it easier to keep it updated over the long term. The choice on whether the data would be freely available at a cost could be a policy decision and the network would support both models.

Design Principles for crafting open data sets

1. Federation by design: Rather than striving for a single centralised data repository covering all relevant data for the sector, it may be more pragmatic to continue to foster an ecosystem where multiple such datasets and data providers exist (even across multiple portals/platforms) each contributing to a broader pool of knowledge available to multiple innovators. It's crucial to note that harmonising the data schemas across all units isn't necessarily required - as long as each data publishing entity publishes the data schema used by their data set.

2. Privacy by design to protect individual identity at all times: Small data sets require special attention when sharing aggregated results to ensure de-anonymisation is not possible.

3. Open Access: It is key to ensure that each dataset is made available openly for others to leverage and reuse effectively through transparent policies.

4. Open Standards: Promoting open standards for data sharing is key to enabling ease of reuse by software algorithms that access and analyse data. Open data schemas and api’s facilitate seamless access to data from multiple sources.

Decentralised non-personal data network

1. Discovery of various types of data sets across various agencies/entities (public/private).

2. Licensing/Contracting: data set licence conditions vary and both parties should contract before download/access.

3. Download/Access: Access methods range from dataset downloads to data-as-a-service models employing confidential computing. Advanced computing methods may establish data sandboxes instead of straightforward availability to enable deep learning networks for model training.

4. Pricing: While some data may be freely accessible, not all datasets are public or free. Public data is typically expected to be freely accessible but with certain analytics can also be made available at a price point. Pricing enables transparency for all players to make informed decisions and a sustainable ecosystem.

5. Update/Feedback cycles: Implementing automatic dataset update notifications ensures timely feedback cycles (for example yearly), enhancing data relevance over time

All of these processes occur across diverse agencies publishing data product/service catalogues within a decentralised network. This is crucial for ensuring that both public and private datasets are accessible within a unified decentralised framework.

The aforementioned architecture pertains to non-personal data (NPD) across public and private systems, whether through download/access or confidential computing models. All operations are decentralised, allowing data set services to be managed and updated by agencies worldwide.

Reference Examples

Note:

Personal data sharing is not in the scope of this document. Personal and Non-personal data sharing require two different approaches across architecture, policy and governance frameworks. Consent to opt in to share data for anonymisation is assumed to be part of the data sharing governance / policies of the source systems/platforms/entities and is outside scope of this document.

Imagine you’re a technical analyst or decision-maker wanting to better understand and predict regional migration flows. For that, you would need to collect and integrate anonymized data from different national open portals and internal management systems to generate regional data intelligence.

What would you need to consider in your data analytics architecture? This exact question we got asked by an international cooperation agency. Here are some insights from that exchange, that can be extrapolated to any other data management initiative.

When it comes to sharing data, the approach varies by region. Some adhere to open data policies, allowing for the free distribution of datasets, while others might implement additional controls based on data sensitivity.

The architecture for processing these datasets typically involves data pipelines, which can be custom-built, adopted from open-source projects, or sourced from licensed solutions.

With anonymized datasets readily available through open portals the orchestration of technical actions to process data in real time becomes the main challenge. This is what we call the Data Value Chain. More specifically, these are the techniques you’d need to put in place:

1. Data ingestion: Collecting data from various sources.

2. Data clean-up: Removing inaccuracies or irrelevant information.

3. Data transformation: Converting data into a suitable format for analysis.

4. Data Analysis: Analyzing data to derive insights.

5. Storage: Keeping data in databases or storage systems.

6. Querying: Retrieving specific data from storage.

7. Visualization: Representing data graphically for easier interpretation.

8. Sharing: Distributing data or insights to relevant stakeholders.

Furthermore, you should implement technical mechanisms for data validation (ensuring data quality and accuracy) and data security (protecting data from unauthorized access) at every process step.

Open source technologies play a critical role here, offering robust solutions built on proven software stacks designed to address such complex use cases.

The functionality and user experience of open-source solutions are typically highly customizable and depend on the specific requirements and desired level of automation of the project. These aspects are context-specific to each project's objectives.

To gain a comprehensive understanding of this domain, one must consider several key factors:

1. Hosting options for the data, such as portals, websites, or servers.

2. Data sharing methods, including protocols, APIs, and file formats.

3. Data representation standards and schemas.

4. Data processing mechanisms, like pipelines and ETL tools.

5. Data analysis techniques.

6. Data presentation and visualization tools.

Initiatives like India's open data portal exemplify how to facilitate data hosting, sharing, and standardization. Platforms like X-road offer a trusted network for more secure personal data exchanges between govt departments. Solutions like Obsrv provide an integrated approach to data processing, analysis, and presentation.

Understanding these components is vital for anyone looking to delve into the specifics of data intelligence and analytics, especially in contexts as dynamic and impactful as regional migration. The journey from raw data to actionable insights is complex but achievable with the right tools and strategies. Data-driven strategies empower organizations to make well-informed decisions, enhance user experiences through personalized services, and employ predictive analytics for foresight into trends and behaviours.

Digital signatures are cryptographic mechanisms used to verify the authenticity and integrity of electronic data. In healthcare, where the accuracy and confidentiality of information are paramount, they play a crucial role in ensuring electronic records remain trustworthy.

Public Key Infrastructure (PKI) is at the heart of digital signatures.

1. Key Pairs: PKI uses two related cryptographic keys: a private key (kept secret by the owner) and a public key (shared openly).

2. Signing: When data needs to be signed, the owner's private key is used to generate a unique digital signature for that data. This process often involves creating a hash of the data and encrypting it using the private key.

3. Verification: Anyone can verify the signature using the corresponding public key. They decrypt the signature to retrieve the original hash and compare it against a new hash of the received data. If they match, the data is unchanged and verified.

While individuals and organizations are common entities using digital signatures, non-human entities like websites, servers, or software can also use them.

Digital Certificates for Websites: Websites use digital certificates to establish secure (HTTPS) connections. The website's certificate, which contains its public key and has been digitally signed by a Certificate Authority (CA), is provided to visitors. This assures visitors they're interacting with a genuine website, not a malicious impersonator.

Data Fields: Individual data fields within larger datasets can be digitally signed, ensuring the integrity of specific pieces of information within broader systems (eg: registries)

In any sector, the stream of personal data generated during every transaction enables better decision-making and service delivery. It’s imperative to empower users by enabling consented sharing of granular personal data in a secure, privacy-protected manner. In any user-driven data-sharing framework, the data consumer needs to request the user for their personal data by specifying the quantum of data required, the purpose it’s going to be used for, the duration the data is needed for, the frequency of data pull etc. This step is a precursor to the actual sharing of data by the data provider. Maintaining logs of the agreed-upon data-sharing transaction in a non-repudiable, auditable fashion is a key check.

Electronic consent is an artefact/ data structure that records and stores the consent for that data-sharing agreement. Technically, it is a machine-readable electronic document that specifies the parameters and scope of data share that a user consents to in any data sharing transaction.

The consent artefact in general consists of the following sections:

1. Identifier section: Identifies and lists all the entities involved in a data-sharing transaction; the data provider, the data consumer, the individual, and any other intermediary

2. Data section: This section describes the type of data & permissions of the data being accessed including the data fields, date range of data, duration of access, frequency of access, etc. The purpose for which the data is to be accessed should be clearly defined as well.

3. Signatures: Each consent artefact should include a signature block with signatures of one or more entities as defined in the framework

The electronic consent framework should be programmable, i.e should allow for condition based consent approval with required checks. (eg: Automatic consent approval for access to blood group, allergies, etc, in an emergency)

Reference : MeitY-Consent-Tech-Framework

A DPI approach to Discovery and Fulfilment represents the capability to avail of any service or purchase any good across multiple apps in an interoperable manner. This can include:

1. Open APIs for government services such as tax filing or business registration

2. A shared protocol for purchase of goods or services across sectors (such as BeckN) including for use cases such as:

   1. Open Mobility/Transport: using any one app or interface, book railways, flights, buses, or cabs interoperably.

   2. Open eCommerce: Buyers and sellers can search any app to view a catalog and place an order for an item, and aren't restricted to just one two sided marketplace app

   3. Open Financial Services: Allows borrowers to view and apply for loans/insurance products from multiple banks/insurers in any app on the network.

Consider this - Buber is the leading ride-hailing app in country A. Buber takes a huge commission from the drivers and also charges the passenger unfairly. Still, both parties are left with no choice but to use Buber due to strong network effects from the aggregation of a large number of drivers and passengers - creating a virtual monopoly. Sounds familar? Read on!

With every passing day, more and more services are becoming digital, often powered by private platforms that have disrupted traditional service providers. Strong network effects and hence concentration of data with these few large players is a pattern we see. Closed-loop marketplaces are the norm. Apps are not interoperable and all the individual businesses have to solve all parts of the transaction cycle, i.e. - discovery, ordering, fulfillment & post fulfillment.

While an aggregator-led model (where both service providers and end users are onboarded to the same platform) seems to work, it does not scale beyond a point. Besides, large aggregators often adopt business policies that are advantageous to neither the service provider nor the end user.

Data in siloes, predatory monopolistic practices, lack of scale, and exclusion of certain population segments - all indicate a need to shift the approach from “platform” to “networks”. Imagine trusted, low-cost, decentralized transactions at scale - this is what open networks aim to achieve!

Reference:

1. https://becknprotocol.io/

Payments are the lifeblood of an economy. Without frictionless and low cost digital payments, commerce is bottlenecked. When payments are largely cash-based without viable digital alternatives,

1. Remote commerce and eCommerce suffers (particularly in the face of physical restrictions or remoteness barriers such as those imposed by COVID); and

2. Physical commerce faces higher frictions and challenges (loss of value due to lack of availability of exact change, increased likelihood of robberies/theft, etc).

While digital payments are not new, a DPI approach is distinct from existing types of digital payments in it they creates inclusion, innovation, and unprecedented scale of access that allows for diverse user experiences (over smartphone, feature phones, or no-phones).

To ask whether the payments in your country is operating as a Digital Public Infrastructure, simply answer this: is a majority of the population in my country, (particularly those of lower incomes) able to access and regularly use a reliable means of digital payment at affordable cost to them? If not, and a payments system is used only by the elite sections of a country while much of the population prefers/relies on cash, there is scope in your country for a DPI transformation in payments that could catalyse the digital economy.

In particular, we explore 5 powerful payments interventions to trigger a DPI transformation:

1. Interoperable QR Code (P2P/P2M Payments)

2. Interoperable Authentication (P2P/P2M Payments)

3. Financial Address Mapper (G2P Social Benefit/Cash transfer Payments)

4. Cash in Cash Out (CiCO) for Interoperable agents in cash withdrawal

5. Interoperable bill payments protocol

All types of transactions - whether between people, businesses, and / or government - can be powered by the same protocol that allows for interoperable payments! The protocol is agnostic to payment device, currency, type of transaction etc.

eSignatures can be built as a capability on top of any identity system. They allow for an individual to avoid a physical or wet signature, and instead sign a document remotely using a method of identity authentication. These documents could include loan agreements, property ownership agreements, or closure of business documents for instance.

eSignature is a protocol that can allow an ecosystem of electronic signature providers to facilitate legally valid signatures as a service to various public and private institutions, typically building on an existing identity authentication and eKYC API.

An example eSign ecosystem could be architected as follows:

Source: https://cca.gov.in/sites/files/pdf/esign/eSign-APIv3.3.pdf

Further resources:

https://cca.gov.in/sites/files/pdf/ACT/eSign-APIv2.1.pdf

Concept

Just the way ‘21/02, House X, Street Y, City Z, Postcode - 000’ is your home address (where you stay), the combination of ‘Bank A/c No., Code, Bank Name + Branch’ or “Card number, Provider, Expiry, CVV” etc. is your financial address (where your money stays).

A few decades ago, the only way to meet people at home was by giving them your home address and inviting them over. So people had smaller friend circles and fewer people in their lives. Soon, Google Maps simplified an entire address to a single, shareable URL which allowed people to have a quick, efficient way of getting their address out. Then email addresses, instagram handles, linkedin profiles and multiple other channels of discovery came along encouraging new connections. People’s social lives exploded, and the world as we know it transformed.

The same is now happening in the financial world for payments through the concept and implementation of a “financial address”.

A financial address is a system that (i) encourages people to transact digitally, from any store of value, to any store of value, while completely preserving (ii) the privacy of the payer/payee and (iii) the trust of the receiver.

A financial address simplifies any store of value to a unique address in the form of “id-type:id@provider”. For example, “mobile:12345@mobile-pymt” (mobile@mobile-provider) or

“account:12345@national-bank” (account-id@bank-psp-code)

Through this, the payment systems know which account to transfer the money to, while hiding these details from the human and machine eye. It creates a routing mechanism that ensures secure transfer of money, while eliminating the chances of fraud, misuse, or leakages through hacking. The resolution of the final store of value account is left to the final entities doing debit/credit actions of the payment.

Advantages

1. Protects privacy of users encouraging them to transact with various parties freely and safely

2. Enhances cybersecurity by preventing the creation of honeypots (large databases with sensitive financial data that can be hacked or leaked)

3. Allows multiple, and ever evolving, stores of value to be conveniently communicated in a standard format

4. Builds P2P and P2M trust - spurring innovation and adoption.

Why Financial Address?

The financial world is continually evolving with new products and offerings to customers.

1. Traditionally bank accounts were identified with customer account number, bank id, bank branch. Overtime, with evolution of mobile and net banking the identifiers have evolved where the branch id is no longer relevant and this got encapsulated with in mobile number/identifier and net banking customer id respectively.

2. With card based networks/accounts, product offering with debit, credit, gift, pre-paid cards the attributes to identify a store of value account keeps changing. e.g., card type, varying length of card number, card type, expiry year/month, cvv, one time tokens, etc.,

3. Digital cash and Crypto cash concepts are continuing to evolve.

In these scenarios, defining a store of value account using a fixed key/value or object structure will not be intuitive and core payment api specifications need to be constantly updated with each new product offering coming into market.

The idea of normative addressing format to represent any store of value account is referred to as financial address (fa). Any payer or payee accounts now can be abstracted to a normative address and resolution of final store of value account is left to the final entities doing debit/credit actions of the payment.

On similar lines, to enable integration with various identity systems/registries of all customer ids can also be represented in normative addressing formats!

Principles

1. Financial address is case insensitive normative representation of a store of value account represented as id-type:id@provider

2. id-type can be a account num, customer id, user id, virtual id, unique id, one time token, pre-paid voucher no, cdbc id, etc.,

3. The resolution of final store of value details is left to the entity holding these accounts at final debit/credit left of the payment transactions.

4. id-type & provider information in financial address shall enable intermediaries in the payment network to route the payment instructions as per the network rules/polices.

Examples

token@id-provider e.g token:12345@national-id
uid@pymt-rail e.g uid:12345@national-id
vid@id-provider e.g vid:12345@national-id
mobile@mobile-provider e.g mobile:12345@mobile-pymt
account-id@bank-psp-code e.g account:12345@national-bank
account-no@ifsc-code.ifsc.pymt-rail e.g account:12345@abcd0000001.ifsc.pymt-rail
user-id@psp-code e.g. joeuser@national-bank
token@psp-code e.g token:123456@a123
code@purpose-code.voucher-provider e.g voucher:12345@food.coupon-network
cdbc-id@cdbc e.g. 12345@digital-cash"

Attributions

1. The concept of financial address is inspired from NPCI's UPI Protocol use of Virtual Address or UPI ID.

When we speak about ‘authentication’, we are referring to the ‘knowledge layer’. Authentication means the confirmation - of the person as well as transaction. Interoperable, in this context, means standardised. Thus, interoperable authentication means the ability to confirm the transaction in a standardised manner.

Why:

As an economy grows, very often through the nudge provided by the DPI approach, a lot of new fintechs emerge in the market. They offer a variety of services like banks do - such as P2P/P2M payments, loans, bill payments etc. However, they have one stark difference - they are unregulated. This gives them the agility the banks lack to adapt to newer trends and technologies but the unpredictability and volatility of creating systemic risk. Restricting their growth means stumping entrepreneurship and the economy. But letting them run freely, means more money leaving the formal banking system and going into unregulated hands. The solution to preventing both these extremes lies in interoperable authentication.

What:

Through interoperable authentication, the central bank can set out a predefined manner in which transactions have to be validated to ensure that money never leaves the banking system. The payment transaction is processed only once the authentication is received in a standardised manner in the form of a PIN, One time password, biometrics, face authentication etc. The fintechs remain the front end of the user-transaction, but the authentication is collected by the payment switch directly on the backend and settled between the banks themselves.

This solves for both use cases - it prevents money from leaving the formal banking system (goal of the banks) and it prevents users from leaving the fintech application to authenticate themselves (goal of the fintechs).

How:

The authentication page is provided as a standard SDK (software development kit) by the payment switch operator. They publish the page that all fintechs have to use, effectively decoupling this layer from the acquiring application to securely capture sensitive info like PIN, OTP, Biometric data with crypto keys for end financial institution to decrypt and authorise the payment. This SDK is integrated within all fintechs themselves so that while authentication is done on their application, it is done without the oversight of the fintechs. This SDK is mandated and has to be used by every payment application (including the banks themselves).

This creates 3 distinct layers, and thus roles, to every payment transaction:

1. User layer: handled by fintechs who can create diverse, custom user interfaces to grow their market share

2. Authentication layer: handled by the payment switch to securely capture private PIN, OTP, Biometric data and verify each transaction

3. Settlement layer: handled by the banks themselves and settled between each other directly on the backend

Benefits:

1. Privacy and Security: Enhances trust by allowing individuals to have a standardised experience while authenticating sensitive information and payment transactions across different applications

2. Reduces systemic risk: by decoupling the verification process from the fintechs, it prevents misuse or leakage of secure pins, password and biometric data

3. Growth of formal economy: it allows the free economy to grow and thrive with the growth of fintechs while ensuring the money never leaves the formal, regulated sector

Why:

Individuals have to pay multiple bills on a monthly basis - electricity, water, loan EMIs, mobile recharge etc. Keeping track of all individual due dates, navigating complex standalone portals and making payments for each is a difficult, time-consuming process. Often, this leads to an increase in missed payments, defaults, and subsequently, higher interest rates for individuals and a weaker economy for the country.

Centralisation of payments through a single portal is not an option - it will create a bulky, slow system that is the target of cyber attacks. It will also cause various departments to lose agency and autonomy over their own collections and create friction in society.

Leaving payments integration to private sector players is not an option either - multiple bill issuers will have to integrate with multiple different applications each, once again causing high friction, loss of opportunities and a monopolistic situation for the first mover.

The only solution lies in establishing interoperable bill payment rails through the Digital Public Infrastructure approach.

What:

Interoperable bill payments means that people should be able to view and pay all their bills through a single platform of their choice.

The bills are federated at the back end, but centralised for user experience.

Through this, the objectives of all parties are met -

1. Bill issuers: They retain control over their own assets, and can decrease the costs of their own issuing infrastructure.

2. Market innovation: It allows a variety of market players to innovate services, platforms and applications on top of the bill payment rails to cater to diverse segments of society.

3. Bill Payers: Individuals now have the freedom of choice, bolstered by the variety of payment applications available to pay their bills through a single platform.

How:

To make an existing billing infrastructure interoperable, all that is needed is to simply open up the APIs (Application Programming Interfaces) of different bill issuing authorities. This enables a variety of user-facing applications to ‘fetch’ the data from the issuers and present it to the individuals through their platform.

The individuals can choose to make the payment directly from that same platform or through any other means such as cash, card or cheques.

The bill data is simply fetched from the issuing server and not stored with the individual applications.

Once the APIs are open, any market player (once it clears the necessary safety measures set out by the central bank) can use it to fetch data based on individual’s consent. There is no need to separately on-board different issuers or platforms over and over again.

Financial Model:

A variety of financial models can be established on top of this infrastructure. One common one being, that every time an intermediary fetches a bill for an individual they charge the bill issuing authority a miniscule amount (0.0x%) of the transaction. The percentage is laid out by the central bank and same for all intermediaries to ensure a level playing field.

This money is the cost of convenience for letting the bill be discovered (and hence paid) by the individual on the application of the individual’s choice. This cost is absorbed by the bill issuer and not passed on to the consumer, thus ensuring that the cost of the bill for the individual across all applications remains standardised.

Benefits:

1. Federated control: Data continues to be stored on individual servers of issuers and is only fetched and displayed upon receiving an API call.

2. Inclusive innovation and Interoperability: The design of the infrastructure allows for multiple market players to innovate services and platforms on top, while ensuring no additional work for bill issuers to integrate with diverse systems.

3. Privacy and security by design: The intermediary applications cannot see, modify or force transactions. It can simply display the bills based on an individual’s consent, who are free to pay through the same application or any other means of their choice.

Why:

Typically, the last mile population is overlooked when enabling financial services through digitisation. Since literacy may be low, access to the formal banking system can seem intimidating to many. They may get lost trying to navigate the complexities of modern day banking such as doing online bank transfers or even checking their balance. Moreover, many local businesses need physical cash - they do not see much value in digital payments. The old adage reads: Banks cannot go to every village, it is simply not possible. Well, banks may not be able to go to villages, but - through the Digital Public Infrastructure approach - banking can.

One of the key aspects of financial inclusion and integrating people into the formal economy is ensuring the last mile population has access to bank accounts. However, if they don’t know how to use it, very often these bank accounts remain idle, and if any benefits are transferred to the account, they remain unreachable for the masses.

The cash in - cash out DPI helps solve for last mile access to formal banking services.

What:

The cash in - cash out system equips select human beings to function as ‘micro-ATMs’. This means that they travel to remote areas of the country where individuals can conduct transactions through their bank accounts using the person as a ‘micro-ATM’. The individuals get immediate access to their money while remaining in the formal financial system.

Cash In: is about securely transferring benefits to end beneficiary by removing intermediaries and remove friction and cost.

Cash Out: is for providing access to physical cash at the last mile to use the direct cash benefits payouts.

How:

The cash in - cash out system is based on a unique national identity system. Basically, the chosen people who are acting as these ‘micro-ATMs’ travel to the last mile populations, carrying a certain amount of money with them along with an authentication device. Any individual can simply provide their bank account name as well as their national identity number and biometrics to authenticate that information. Using this, the micro-ATM can pull up their bank information on their device.

On the backend, a financial address mapper links every unique national identity number to an individual’s bank accounts. Once the bank name is provided by the individual, it can accurately connect to bank servers, find the match, and pull up that data for the individual to use.

Now once again, by providing authentication through their biometrics, individuals can:

1. Deposit cash

2. Withdraw cash (remember, the Micro-ATM is carrying money with them)

3. Transfer money using only another person’s national ID number (no bank account details necessary)

4. Pay bills

5. Check bank balance

6. Generate a mini-statement

All these facilities are available at no additional cost to the end-users.

While the micro-ATMs are essentially agents of one particular bank (and receive their salary from them), they cater to customers of banks across the country without discrimination.

The benefit to the banks is that it allows expansion of the society into the formal financial sector who can avail a variety of services which would have otherwise not been possible.

Benefits:

1. Financial inclusion: it caters to the underserved sections of society while elevating them to the next level by providing them with access and empowerment through formal finance.

2. Interoperability: it allows for diverse banks to access the last mile population and enable national identity based transactions through a central switch and clearing agency.

3. Privacy and security: the method of authentication using biometrics is inherently safe as it cannot be forged or duplicated by the micro-ATMs. The privacy of individuals is ensured by not revealing any sensitive information and only enabling basic banking transactions through this facility.

In its daily workings, governments across local, state and national levels make various payments to people of a country. This may be in the form of subsidies, pensions, scholarships, incentives during emergencies and more. Citizens may choose to receive these payments in different ways such as through cash, bank transfers, mobile wallets, prepaid vouchers, etc. These payments are made across various departments at different levels of functioning.

While each transaction may vary in amount or eligibility, there are a few common steps of executing any g2p payment:

1. Checking for eligibility of the beneficiaries according to pre-set scheme criteria using data from federated functional registries

2. Authenticating the identity of the eligible beneficiaries using online/offline, self/assisted modes

3. Mapping the authenticated, eligible beneficiaries to a store of value of their choice in which they choose to receive these payments using multiple payment rails

A G2P DPI is about building an overarching architecture as a simple +1 step to your existing systems that ensures interoperability, inclusions, privacy, security, autonomy and asynchronous adoption by design.

The Unique ID / eKYC layer allows for uniquely identifying and authenticating each individual within seconds, saving time + effort + leakages on both sides.

The Financial address mapper connects an identifier to the individual's store of value of choice to receive the payments thus facilitating secure transfer of money to them.

The last mile agents help those with little to no digital literacy access the same benefits using their biometric data to drive financial inclusion from the ground up.

The network of cross functional registries help identify and sort individuals according to the eligibility criteria of various schemes while keeping the data decentransiled. It allows for autonomy of departments while building interconnectivity to drive efficiency.

There are few key learnings that make the G2P DPI approach unlike any other:

While individual country adoptions may vary, the basic outline remains the same and can help countries rapidly deploy this approach.

Further readings:

1. The G2P blueprint

2. A presentation deck on the G2P approach

Overview

Imagine a one-stop feature that your country can build to bridge the digital divide, drive financial inclusion to the last mile, break payments silos, drive e-commerce and GDP, reduce financial crime rates, and spur cross-sectoral innovation - all whilst leveraging existing systems.

Payments made based on an interoperable Quick Response (QR) code standard allow people to make payments to anyone, anytime, and anywhere. Payments can be made in a real-time, and highly secure manner with this digital public infrastructure that allows people to scan a machine readable QR code through any payment application of their choice on their mobile, regardless of which payment app the merchant uses.

QR codes can be made interoperable if a standard is set out by a central authority, and can allow a user to participate in a single network of banks, financial institutions, mobile money, wallets, or other payment mechanisms on the backend. This can be a simple and powerful addition to existing payments systems.

QR Codes can be of two types:

1. Static QR Codes: Bill amount has to be manually entered - it is a single code and can be printed as it does not change with each transaction.

2. Dynamic QR Codes: Transaction amount is pre-entered by the merchant by connecting it to a PoS terminal.

Through Interoperable QR Codes:

1. Countries can facilitate seamless payments such as P2P, P2B, P2M and various other entities

2. Merchants can automate the reconciliation of orders and payments, as well as generate receipts and notifications by integrating with existing accounting platforms.

3. Individuals can set up Recurring payments, Bill Payments etc.,

4. The last mile population can be catered to, and raised to the same level of financial inclusion through digital transformation.

5. The rate of fraud will drop, while increasing privacy, security, transparency and trust across the ecosystem.

P2M Ecosystem Players

1. Merchant

2. Merchant acquiring bank

3. Customer

4. Customer bank

5. Interoperable payment network switch

Additionally, experience layer at merchant and customer can optionally be supported by payment service provider app by fintech ecosystem connected to banks.

Specifications

{
  "version": "1.0.0",
  "payee_fa": "joeuser@national-bank",
  "payee_name": "Printing & Stationeries Co",
  "amount": "138.50",
  "amount_split": {
    "sale": "117.37",
    "igst": "21.13"
  },
  "init_mode": "POS",
  "currency": "ZAR",
  "mid": "M-12345",
  "pos_id": "POS-123",
  "expiry": "20230605T101225+5:30",
  "order_id": "2023/123456",
  "ref_url": "https://printing.co/orderId=2023/123456",
  "additional_data": {
    "bill_number": "123",
    "reference_no": "PO123",
    "key1": "value1"
  },
  "sign": ""
}

Deep Linking

QR code content can also be represented in URI representation to enable single QR spec in Deep Linking. Deep Linking enables sharing the scanned QR codes across mobile applications with in a device to easily transfer control from business app to payment apps.

It is recommended to represent the JSON QR code spec in URL encodded format. URL encoding shall ensure to accomodate JSON nested attributes in string represenation to carry in an URI.

xxx://pay?%7B%0A%20%20%22version%22%3A%20%221.0.0%22%2C%0A%20%20%22payee_fa%22%3A%20%22joeuser%40national-bank%22%2C%0A%20%20%22payee_name%22%3A%20%22Printing%20%26%20Stationeries%20Co%22%2C%0A%20%20%22amount%22%3A%20%22138.50%22%2C%0A%20%20%22amount_split%22%3A%20%7B%0A%20%20%20%20%22sale%22%3A%20%22117.37%22%2C%0A%20%20%20%20%22igst%22%3A%20%2221.13%22%0A%20%20%7D%2C%0A%20%20%22init_mode%22%3A%20%22POS%22%2C%0A%20%20%22currency%22%3A%20%22ZAR%22%2C%0A%20%20%22mid%22%3A%20%22M-12345%22%2C%0A%20%20%22pos_id%22%3A%20%22POS-123%22%2C%0A%20%20%22expiry%22%3A%20%2220230605T101225%2B5%3A30%22%2C%0A%20%20%22order_id%22%3A%20%222023%2F123456%22%2C%0A%20%20%22ref_url%22%3A%20%22https%3A%2F%2Fprinting.co%2ForderId%3D2023%2F123456%22%2C%0A%20%20%22additional_data%22%3A%20%7B%0A%20%20%20%20%22bill_number%22%3A%20%22123%22%2C%0A%20%20%20%20%22reference_no%22%3A%20%22PO123%22%2C%0A%20%20%20%20%22key1%22%3A%20%22value1%22%0A%20%20%7D%2C%0A%20%20%22sign%22%3A%20%22%22%0A%7D

Stress Testing

Above specification has been stress tested for below use cases. Sample JSONs are provided for easy reference.

Technical Considerations

1. Signed QR code content is mandatory to ensure security and detect any malicious requests / phishing attacks.

2. Scanning of QR codes and verification of digitally singed QR code content is the responsibility of the payment apps on customer mobiles.

3. Payment Network provider shall manage the registry of all acquiring banks authorised to onboard merchants and offer digitally singed QR codes.

4. QR Codes perform well if information is sparsely packed for all types of devices displaying and scanning can optimally perform. Where possible, implementers are recommended to use short URLs and optimise size of overall QR code. This QR specs ensured to keep the json attribute values short.

Typical flow

Below is a typical flow to make initiate merchant based QR code based payments:

1. Merchant signs up with acquiring banks to available QR code based payment service

2. Using merchant's banking interface, merchant requests a static QR code

3. Additionally merchant may integrate with POS terminal to generate dynamic QR codes using APIs for each transaction with amount and other customised attributes like description, tax info etc.,

4. Customer using her payment app scans the interoperable QR code

5. Payment app checks signed QR code scanned is non-tampered and is from trusted source. Uses network registry to identify the acquiring banks

6. Customer payment app provides a choice to customer to select linked accounts to pay for the transaction

7. Customer payment app securely collects banking account pin to authorise the payment from the customer

8. Customer payment app initiates the payment on interoperable payments network to pay to the merchant's account

9. Notification of payment status is notified to merchant and customer by the respective banking apps.

Additional References

1. Interactive closed-door discussion on Scaling Inclusive Payments through Interoperable QR Codes with central bank officials of 30+ countries and speakers from Brazil, India, Philippines, and Nigeria

2. Presentation Deck summarising the need, benefits and specifications of interoperable QR codes in a simple, visually-appealing manner

3. QR Code printing specifications <coming soon>

4. The use of quick-response codes in payments Part of World Bank Fast Payments Toolkit Sep 2021

Attributions

In many ways, 2023 was labeled as ‘The Year of DPI’ (at least for those who work in government, the development sector, or tech-policy institutions!). This year, a concept relatively new in terminology but fairly mature in global practice was brought to the forefront as a powerful strategy to accelerate socioeconomic growth. It was able to not only withstand the scrutiny of top bureaucrats, policy leaders, and private entrepreneurs across the globe but also fostered a global consensus on the suggested principles for building DPI - which is a rare feat!

Of course, now that there is consensus on the need to build DPI to accelerate growth and development, it falls on the executors in countries - how do we build DPI at an accelerated pace to benefit citizens?

The Centre for DPI is:

1. Software neutral (we have no product offering of our own and can provide tech architecture advisory regardless of the software you use)

2. Technology neutral (we are happy to support countries regardless of whether they choose open source or private procurement)

3. Financing neutral (we don't provide funding or take any money for our services, we are philanthropically funded and work on a pro bono basis)

4. Government neutral (we are a global team, happy to work with any interested government and have no political alignment)

5. Country neutral (our team spans 5 countries, 3 continents, and we work with global dev partners, tech providers and funders without preference for one over another)

At CDPI, we are only biased towards one thing: Implementation!

Whichever country, government, funder, technology and software can help DPI implementation roll out in accordance with best practices, and fast timelines, we are happy to support them and work with them to promote global DPI implementation in the country's best interests.

CDPI has team members who have rolled out DPI projects at scale in their own countries, and continues to do so in various contexts (including Daniel Abadie who oversaw Argentina's verifiable credentials system, Emmanuel Khisa who worked on ID and Payments in Africa, and Pramod Varma, the chief architect of the India Stack)

Any country can approach CDPI (please email info@cdpi.dev) to engage with us. CDPI can help share some knowledge and insights on the best practices to adopt while designing their digital transformation journeys to ensure they reach scale in sustainable manners, power public and private innovation, and are able to create interoperable, reusable building blocks with minimal funding and resource constraints.

The engagement with CDPI can be as low-touch or intensive as the country chooses. Since CDPI doesn't undertake any project management, funding or software offering, the complete control over the engagement remains with the country, with CDPI supporting however the country sees fit.

There are three levels of engagement typically carried out between a country and CDPI. The engagement can progress from one level to the next as per the country's interest and progress.

1. Conversational: Where CDPI informally talks to country representatives to understand the ecosystem, provide broad guidance on the DPI approach, best practices, powerful +1s to existing initiatives etc. through virtual calls.

2. Co-Creation: Where a country chooses to engage with CDPI on a specific use-case or project to collaborate on a detailed strategy note, align stakeholders, build out the tech architecture etc. through virtual calls that may be accelerated through physical visits if required.

3. Roll-out Action: Where a country is rolling out the DPI pilot or project in line with the advise received from CDPI and its other stakeholders, and needs continued support as they reach scale.

For more information on how CDPI can engage with countries, please feel free to reach out to us at info@cdpi.dev. To understand how CDPI can provide pre-packaged DPI product, policy and program management kits for rapid deployment, please see DPI as a packaged Solution (DaaS).

Challenges of Current DPI Implementation that DaaS Seeks to Address

The ground realities of implementation vary not just from country to country, but also by region. Yet a few common challenges in DPI rollouts persist across contexts:

1. An inherent friction between need and speed of rollout: the need for the DPI is urgent for people, but there are often challenges in speed of implementation;

2. The local capacity to architect and build minimalist technology infrastructure solutions may be low or vary at different levels of government;

3. There may be funding or budget gaps for execution (not just for the new software systems but also for compute/hardware); and

4. Procurement cycles may be long and tedious to kickstart progress. There are multiple hoops to jump through before a country can even test out the DPI block through a pilot. Some of these are shown below, indicating the complexity countries often face: many have a selection process to identify the team that would eventually craft the RFP to identify a final system builder.

These execution pains are real! Often, initial planners are unable to anticipate the exact system requirements eventually needed in nationwide infrastructure. They feel the need to anticipate and prepare for all eventualities which is an extremely time-consuming process and often doesn’t bear fruit. The future is ever-changing. The DaaS framing helps to keep the current context in mind while simultaneously allowing future innovations to be extensible in the future with minimal changes to its foundational protocols and systems. Creating optionality is a powerful strategy for large-scale digital projects.

In many countries there is no demonstrated proof of success to show others that the DPI approach will work at an unprecedented scale - when applied to a specific use case, in that context, and for those outcomes. A DaaS phase one implementation rollout can help establish this conviction.

The pre-packaged DaaS kits offer an easily deployable model for various DPI building blocks through packaged product pilots. Through DaaS, you can easily demonstrate proof of success of the DPI approach for your use case, country, context, and outcomes - helping build traction for a full-scale rollout.

The DaaS products significantly reduce the time, cost, and workforce required to build local, use-case driven DPI. While open-source projects offered by Digital Public Goods (as shown in the diagram above) reduce the time taken to build core DPI components, they do not today reduce the time needed for deployment, and technology management infrastructure.

DaaS combines best-in-class open-source DPGs with a new class of pre-trained technology service providers to pre-package DPI for ready deployment for pilots. In addition to this, it combines program and policy guidance so that the time to deployment of the DaaS package is further reduced.

DaaS thus leverages best-in-class Digital Public Goods (DPGs) to create a pre-built package that every country can use to test out a pilot, using a set of pre-trained Technology Service Providers. Countries retain full control over the pilot and all systems built (including the IP), and can customise (by adding extensions) the systems post the pilot and before they scale.

Countries can also select the type of cloud they prefer - public or private clouds - to drive growth, inclusion and scale. Private clouds may be more appropriate under some data protection regulatory frameworks. Countries can also choose to host the package on-prem if they have the hosting infrastructure.

DaaS is not very different from what governments already do today!

DaaS brings together elements that have been a part of digital governments and national infrastructure building for generations:

1. Cloud (public or private) is not new - it is used for a variety of government digital services.

2. Packaged product software purchases are not new - they are part of routine government operations (such as through the Microsoft suite, Email providers, etc.)

3. Open Source DPGs are not new either - multiple governments use open-source components such as X Road for data sharing or open protocols for best-in-practice tech principles.

DaaS is simply a combination of these things - a small innovation that we believe could have a big impact.

DPI as a packaged Solution (DaaS) refers to rapid deployment of DPI, through upgrades of existing infrastructure (instead of greenfield implementations) through non-procurement routes.

There are multiple operational modules for DaaS:

1. Benefit from Open Source Artefacts + Funded & Pre trained Service Provider: Countries can choose to join the funded DaaS program to receive pre-packaged offerings of their chosen product (digital public goods), and pre-trained service provider (trained by the digital public good owner) to support deployment, along with policy frameworks, program management kits, legal templates and costing models.

2. Benefit from only Open Source Artefacts: Countries can also choose to reuse any of the reusable implementation DaaS artefacts to rapidly upgrade their existing systems to DPI (for example, reusing an eSign module to add authentication on any ID) using an existing vendor, at their own cost and according to their own timelines.

3. Benefit from only Pre-trained Service Provider: Countries can also choose to deploy an offering from a private pre-existing vendor who has been trained under the DaaS program by the DPG owner

The reason DaaS stresses on non-procurement is to ensure rapid deployments of minimalist DPI blocks that can exponentially increase benefits to individuals and institutions in society - and procurements by governments, while necessary in some cases, tend to be a year or two long process and are not required for simple upgrades to existing systems.

DaaS differs from traditional pilots or POCs because the infrastructure is built for population-scale from day one using country resources and capacity, and can reach full coverage in a matter of months. This is supported by the fact that DaaS applies only to minimalist layers such as authentication on top of existing ID (and not ID enrolment itself - which even on a best-effort basis would take years to cover the whole population).

Regardless of whether countries choose to join the funded DaaS cohort or independently execute DPI blocks, it can be helpful to reuse some standardised DPI artefacts that can help expedite the process of execution, regardless of the DPI block chosen, the choice of vendor, or the scale of execution.

DaaS will fast track DPI adoption to any ‘hard to reach areas’, applicable beyond the globalisation effort.

•⁠ ⁠reusable for sub national/state level adoption within any large countries (such as state level registries)

•⁠ reusable wherever decentralised private adoption of a module is required (such as verifiable credentials)

A presentation on DaaS can be viewed here:

Regardless of whether countries choose to join the funded DaaS cohort or independently execute DPI blocks, it can be helpful to reuse some standardised DPI artefacts that can help expedite the process of execution, regardless of the DPI block chosen, the choice of vendor, or the scale of execution. These artefacts are templates co-created with the larger international DPI ecosystem to standardise the process of implementation. They can be modified as required to suit a country's needs.

These artefacts include:

1. Execution readiness checklists - helps countries assess their current infrastructure, map out use-cases and stakeholders, and gain a comprehensive understanding on some of the pre-requisites to executing DPI in a scalable and sustainable manner.

2. Legal arrangement templates - including a draft Letter of Intent between the country and any open source provider, as well as a back-to-back Memorandum of Understanding between the open source provider and a service provider that can support in country deployment, in line with privacy, security and critical DPI safeguards built in.

3. Sample costing models - an indicative costing model that reflects the typical price ranges of a minimalist DPI execution by leveraging an open source product, irrespective of geography. It also outlines standard team structures based on the technology and program requirements that can support DPI execution. The costs represent extensive consultations with multiple international and local private vendors and open source products across the world, on a range of DPI blocks, based on their prior experience executing similar infrastructures in other countries.

4. Policy kits - sample strategy papers that outline the context, challenges, DPI recommendations, mechanisms for implementation and benefits that can be tailored to suit any country and any DPI block for rapid understanding by, and alignment of, key stakeholders in the country ecosystem.

5. Program rollout guidelines - highlights the recommended activities that must be conducted during the pre-assessment, training, build, rollout and scale stages to ensure that there is adequate local capacity, alignment, and momentum for the DPI to reach full maturity.

The DaaS Playbook for rapid deployment of DPI pilots has been open sourced and linked below.

Design thinking behind the artefacts:

1. Focused on the country's ability to rapidly execute without recreating standardised documents

2. Priorities a country-first impact-first lens by including rigorous privacy and security measures across all artefacts in line with best practices and global DPI safeguards

3. Co-created with an international ecosystem of development partners, open source providers, private innovators and vendors, and funders for global accuracy, adaptability and acceptance

4. Agnostic to the type of DPI block built (suitable for all upgrades to existing DPI and not necessarily all greenfield DPI implementations)

5. Designed for agile, minimalist country teams to mobilise larger ecosystems that can support their vision

Piloting DPI via DaaS is now a simple 3-step process!

1. Countries can choose the use case they want to pilot after reviewing the products on offer

2. Have conversations with CDPI, DPGs, and ecosystem market players to understand and procure the DPI DaaS package

3. Configure it to their systems and infrastructure with the help of pre-trained Service providers who can support (along with the DPG) building local capacity for long term scale and sustainability of the DPI.

How DaaS Solves Speed, Cost, Data Ownership, and Capacity Constraints

The benefits of the DaaS approach are manifold:

1. Significantly faster rollout

2. Less costly due to minimal upfront costs, smaller teams, and use of open-source components

3. Clear government ownership of the core IP of the system, data, and cloud instance

4. Significantly reduced tech capacity requirements

5. Ability to shift from input (capex) to outcome (opex) based costing (i.e., pay per user, not for each input cost)

6. Can help tackle incumbency issues to demonstrate proof of concept as a convincing argument

7. Choice of one or more service providers at the same time

8. Choice of clouds and portability

9. Achieve scale and speed to de-risk churn and changes within the system

The DaaS program is a competitive application process where countries can make the case for why they are best suited to quickly implement and scale DPI through the DaaS module in their own countries.

Timelines & Actors in the first wave

The selected countries will be given their DaaS packages as well as supplementary funding for DPI rollouts by June 2024. The phase one of the DPI roll-out will be launched in 90 days and sustain for another 90 days (making the program duration a total of 180 days) to demonstrate sufficient proof of success. Post the completion of the funded program, the country and DPG can mutually choose to extend it for more time (or another use case), or start the transition to scale.

1. The Centre for Digital Public Infrastructure and EkStep Foundation are joint convenors of the program

2. The first cohort is being executed in partnership with IIITB/EkStep (as open source DPG owners depending on the product)

3. Countries undergo an assessment process to ensure they are ready to execute a time-bound roll-out for higher chances of success.

A Final Snapshot: What’s on Offer?

1. DPI Product Packages Available: Digital authentication, Digital Credentials, ID-Account mapper

2. Ecosystem Support Provided: DaaS package (provided by DPG providers, certified implementation partners & cloud providers) and Technology Service Providers to implement the DPI.

3. Funding Sources: DaaS-based pilot funds from philanthropy, Govt funders, and other sources to launch DPI

4. Timeline to launch: Countries can reach out to CDPI to be a part of DaaS pilots at info@cdpi.dev, the support for roll-out and funding will be released after initial rounds of conversation and country assessment (~2 months)

A more visual representation of the above playbook is attached below:

In the first wave, DaaS is being offered in the following categories of DPI Building Blocks (in Identity, Payments, Data Sharing):

What is it?

Add the capability of authenticating whether the individual who owns any kind of ID is trying to use it for a context (eg. via mobile one-time password, PIN, fingerprint auth, or other modes)

Why Digital Authentication?

What use cases can be powered?

eSignet - Additional resources:

eSignet - Experience centre:

What is it?

Enables mapping of beneficiary IDs with bank account information for use cases such as payment of government to person benefits

Why ID Account Mapper?

What use cases can be powered?

Additional resources:

Experience centre:

Coming soon!

What is it?

Convert any paper certificate, license, or statement into a verifiable certificate with a signed QR code, with a document wallet app to fetch multiple credentials

Why Digital Credentials?

What use cases can be powered?

This document below outlines a call to action for software vendors (ISVs) to adopt a user-centric, verifiable credentialing infrastructure that ensures secure, low-cost, and trusted digital data sharing across sectors.

Inji - Additional resources:

Inji - Experience centre:

The upcoming DaaS cohorts will have Civil and Functional Registries and AI Assistant (with open APIs) as a ready-to-implement DPI block along with all the products of cohort 1. Details of the final set of product offers are being finalised.

Reach out to us at info@cdpi.dev for more information or if you would like to participate in the upcoming cohorts as a DPG, Funder, Service provider, or Technical Advisory provider.

Please see the DaaS legal framework here

Q. What’s the overall legal framework of DaaS?

A. There are 4 parties involved in DaaS:

1. DaaS Country Partner - the Country department which is executing the DaaS package

2. DaaS DPG Partner - the DPG which is providing the DaaS product to be deployed in the country

3. Service Provider(s) - the entity(ies) that will deploy, maintain and provide the technical support during the pilot of DaaS

4. Advisor - the partner covering all advisory ( managerial, technical, legal etc)related to DaaS. For the first cohort, this will be the Centre for DPI.

These parties interact with each other in the following ways:

1. LoI or MOU between DaaS Country Partner and DaaS DPG Partner

2. Ecosystem Participation Terms signed by all SPs and DPGs part of the DaaS ecosystem

3. MOU or LoI between the DaaS Country Partner and the Advisor (optional)

Q. Why have we standardised a DaaS MoU at all for DPI Pilots across multiple countries and across multiple DPGs? Can’t we use an existing MoU template that may be country-specific or DPG specific?

A. The way DaaS pilots will scale in a safe and orderly manner across countries and various building blocks is via standardisation of both technical products as well as the legal and governance framework. The key advantages exist of leveraging a standard MoU are:

1. Accelerated Funding for Countries: The MoUs have been crafted in a manner that builds comfort for funders and DPGs on various topics, such as data governance; institutional ownership; timelines, etc. We can only guarantee speed of funding approval with the standard DaaS MoU.

2. Timely kick off of pilot: Existing MOUs or agreements may contain custom formats or clauses that are different from the standard MOU language provided. This customisation could delay the approval cycles for the DPG counterpart and disrupt the fundamental target of DaaS which is rapid deployments of DPI pilots.

3. Multi-DPI Scale Up Potential for Countries: Once a DaaS MOU is signed, annexes to same MOU can be reused by the country for additional DPI blocks offered by the same DPG in the future. Once an MoU draft is approved, it becomes a precedent for other departments in the country to use the same draft to deploy DPI blocks offered by different DPGs in the future.

4. However this is only a recommended option. In case a country, due to its legal and administrative contexts, require a different MOU, that can be considered by adding a country specific annexe

Q. How is this MoU designed to scale up to multiple countries with different contexts; different types of DPI products, etc?

A. Typically, the negotiation process for MOUs can act as roadblocks that delay rapid deployment. This is why in DaaS, we have created a standard MOU template that all parties can use to get swift approval from the legal teams and immediately trigger approval and execution cycles. The MOUs are designed keeping the best interests of the country at the forefront whilst allowing for an acceptable framework for DPGs housed in various institutional contexts. It allows for a range of DPGs and SPs to participate in the program, giving countries the optionality and agency to choose their partners without being locked in to a particular vendor. Depending on the specific DaaS product being deployed and the type of implementation (cloud-based, on-prem etc), a standardised annex can be added into the MOUs to reflect the details of the execution.

Q. Does this MoU change if I choose an on-cloud vs an on-prem locally hosted DPI?

A. No, it doesn’t. The choice of hosting the DPI (private cloud, public cloud, on-prem) is a choice for countries when deploying DaaS. A standardised annex is available for both options that can be incorporated into the MOU depending on the country’s choice.

Q. Does the MoU mention the specific Service Provider that will be deployed by the DPG in the country, along with their roles and responsibilities?

A: No, the MOU between the country and the DPG only lays a framework for DPGs to engage a service provider(s) to provide technical capacity and support for deployment in the local country context. The MoU is service provider agnostic. Please note that the selection of the Service Provider may happen after this Country-DPG MoU is signed and the SP may be adjusted/augmented if the execution cycles of the SP do not meet the benchmarks set by the DPG. The roles and responsibilities of the SPs are mentioned in the Ecosystem Participation Terms signed by all SPs and DPGs.

Q. Will the Country-DPG MoU be available in a language other than English for countries for whom English is not the native language?

A: Since DaaS is a program offered globally, we have had to standardise the language in order to help in scale. Due to this, the standard language for MOU is English. However, the MOU can be translated into any language by the DaaS implementer for their own records and reference. Since it is difficult for us to check the accuracy of translated MOU, in case of a dispute, the English language MOU will be considered as the legal basis for the DaaS engagement and be the version of the MOU that is valid in the court of law.

Q: Why have an MOU between a country and a DPG, when it is not the DPG who will ultimately implement the product in the country, but rather the DPG will outsource it to a third party (service provider)?

A: The DPG is the ‘DaaS DPG Partner’ which means that it is the responsibility of the DPG to support implementation of the DaaS package in the country. To do so, it may utilise the support of a SP or multiple SPs to help with capacity building and technical execution through a separate MOU. Since the DaaS product is owned by the DPG, they will be responsible for training the SPs and ensuring that the deployment adheres to best practices.

There are multiple reasons for this:

1. Countries are assured to get long term support on the open source software like communications on sunset versions, backward compatibility upgrades on support community versions, community connects, etc. that can help ensure that the product is always adhering to the latest technology standards and industry best practices.

2. In the current DaaS design funders can’t directly fund countries and the money shall be routed through the DPGs to DPG trained and implementing svc partners. In future, there can be other models to route funds and similar MoU templates will emerge.

3. In this model, countries don’t have to go through time consuming RFP routes to pick implementation partners. They can quickly deploy DPI pilots to demonstrate proof of concept and proof of success for the products in their own contexts. Post the pilot, countries are expected to find long term svc partners as per countries processes.

4. DaaS is about packaging policy, procurement, core product software, pre-built / configured solutions, training etc. This MoU is a template to expedite roll out with equal balance of speed and of ensuring that a country's independence and sovereignty is protected.

5. In the current design, Svc Providers have a back to back agreement with DPGs to ensure all obligations are delivered through them. This keeps all 3 parties (country + DPG + svc) aligned on the same track and moving efficiently.

Q. How does this MoU ensure data protection and privacy, along with cybersecurity in my DaaS DPI implementation?

The country owns the implementation. The data resides in servers , either on prem or on cloud, which are directly and totally controlled by the government. The data is encrypted at all levels. Neither the DPG nor the Service providers will have access to data , unless the country allows for a specific purpose for a specific time and that too under the watchful eyes of a country administrator

Q. How does this MoU protect against exogenous shocks, like a political or economic crisis that may prevent the progress of the pilot?

A. This MOU allows parties to pause or terminate the engagement in the event of political unrest, a breakdown in public order, natural disasters, natural, health or political emergencies, war or civil disorder or any governmental action that renders the performance of the terms of this MoU impossible. This allows all parties to safely pause or exit the engagement with least collateral damage, and perhaps, re engage when the situation warrants.

Q: What does CDPI/ EkStep get from this?

A: Nothing, in monetary terms. CDPI is a philanthropically funded organisation, and can thus, provide pro-bono support to countries to build their own DPI. DaaS is an easier path for countries to securely, efficiently deploy DPI which aligns with our mandate and mission of driving countries’ digitisation journeys. EkStep is a non-profit organisation that builds DPGs that contribute to DPI, such as AI Assistant which is a part of DaaS. They have a relationship with cloud providers and hyperscalers, as well as experience in high-scale ecosystem technological deployments to guide on design of standard artefacts, thus aligning with their mandate. The only request we frame for countries to ‘give us in return’ is their commitment to engage their best people and resources in order to help make this a successful project for themselves, and associated third parties who are putting a lot of effort into this.

Inviting DPG participation for DaaS

We wanted to share some exciting updates with you!

To accelerate the global 50-in-5 DPI Adoption target, the Centre for DPI and EkStep Foundation are co-convening a program for rapid deployment of DPI pilots called DaaS. The idea of DaaS or DPI as a Packaged Solution was first introduced in a paper published by the Carnegie Institute and later put up for discussion at the Global Technology Summit. The program has been designed after taking feedback from key development partners, funders, DPGs, and government agencies. We have published this wiki for a detailed explanation of how DaaS pilots will be structured.

In the first edition of the DaaS program, the following products (Digital Authentication (on top of an existing ID system); Verifiable Credentials; G2P Financial Address Mapper (ID-Account Mapper); and AI Assistant) are planned to be made available as packaged, cloud-ready, ready to deploy DPIs for participating countries based on country demand.

There are around 7-8 implementation-ready countries in the pipeline for current and upcoming cohorts across Latin America, Africa, and Asia.

We would like to extend an open invitation to you as DPGs to participate as partners for the existing packages of products and for future packages of products. Please let us know if you believe that an open-source project you have could provide one of the products above. The next products we are anticipating to add will be Civil and Functional Registries accessible via open APIs.

Your participation will be key to scaling the DPI implementation across countries. We request you to express your interest in participating by filling out this short form. You can also share this invite directly to any DPGs you believe is suitable. After the initial expression of interest, we will organize a virtual webinar to answer questions and officially onboard DPGs in the DaaS cohorts.

We anticipate that this model will play a critical role in deploying DPI at scale, thereby helping us achieve the ambitious goal of 50-in-5. We are thrilled to have you join us on this exciting and impactful journey. Looking forward!

Regards,

Centre for Digital Public Infrastructure & EkStep Foundation

A common misconception may be that by participating in a DaaS pilot program, a country will be giving up complete control over infrastructure that caters to essential services. However, this is simply not true. Countries retain full control over the DaaS pilot and they are especially beneficial for short-term pilots demonstrating proof of success for the DPI approach.

Common thoughts that may arise || The answer to all is DaaS…

DaaS is a necessary but not sufficient innovation. It may not solve all technical capacity or funding problems but is a necessary first step to simplifying DPI adoption in countries.

Additional FAQs

Is DaaS only a cloud solution? What if I have data sovereignty and data localisation concerns with cloud?

To ensure speed in demonstrating proof of concept and proof of success, we advise countries to use a private or public Cloud. A cloud like computing environment makes deployment of DPG packages extremely simple and fast.

However, either way, Cloud is NOT compulsory for DaaS! DaaS can be a non cloud on-prem environment as well. The key criteria is for the countries to provision compute, storage and network infrastructure to quick installation of DaaS packages. In case of public cloud the opex costs are included in the funding whereas in case of on-prem hosting, countries are required to provision the infra and key infra support personnel from the existing setup and are not part of the funding.

What if I have poor network connectivity and very high data cost for usage of internet or VPN or leased line?

Like all Digital Public Infrastructure, DaaS solutions too are designed to work for last mile populations that may have poor network connectivity or high data costs. Alternate capabilities for users (the way UPI or verifiable credentials that can work with network, without network (offline), with smartphones, feature phones, voice based etc), etc. be Depending on the DaaS DPG package, many of these capabilities are baked into the design itself and can be rolled out by countries as per their need.

How much will I save in terms of time and money? Give me concrete examples. What if the service providers raise the subscription rates?

Our hypothesis (based on our work with countries), is that usually it can take up to 24 months to roll out a pilot DPI program since countries have to undergo various cycles of approvals, definitions, procurement, funding, and build phases. DaaS approach will bring down this time period to 8-12 weeks (to launch a pilot based on a pre packaged, pre-templetized DaaS package).

For the duration of the pilot, if and when a commercial Service Provider (SP) is involved, their rates can be fixed to avoid custom price discovery and negotiation by each country.

Once the pilot is over, the countries can choose to extend the contract with the same SP who handled their pilot, or switch to another one, depending on the terms finalised between the two parties independently.

What do I own and what do I not? Is it like renting a house Vs owning one?

The country will own all the infrastructure of DaaS.

This includes the core IP of the underlying open source DPG, and full control (management and data) of the systems deployed under DaaS pilot.

It is not like owning vs renting a house. Think of it as building a house from scratch brick by brick, vs buying a readymade house which you can move into quickly where the foundations are ready but you can do your own customisations as you use.

Is it really so easy? Have you done it before?

It is a plug and play if you select one of the cloud options; however, it will require some configurations and extensions according to local country contexts, systems and need. This will be a minimalist effort provided by the Service Provider that goes into ensuring the ready packaged DPI solutions (DaaS) work in a manner best suited to your goals.

None of the concepts of DaaS are new - cloud is frequently used by governments, as are packaged software solutions, and DPI. They have all individually demonstrated ample proof of success. DaaS simply combines and harnesses the power of these existing innovations and infrastructure to enable rapid deployment of socioeconomic projects.

Won’t we get locked in to cloud service providers like AWS or Azure or google? How easy is it for me to move from AWS to Azure? Are there are multiple commercial companies providing same services (like I can switch from uber to ola for transport).

Since DaaS core packages are fully open source, the possibility of vendor lock-in issue is minimal. Core DaaS packages are built cloud-neutral and will be tested across clouds.

Moreover, multiple SPs will be offered for each DaaS product category that the countries can choose and re-choose between as per their need and preference to create a choice of vendors

When can I see a pilot of (some service), at a sandbox level

DaaS is first being offered as a pilot itself. It is not to immediately scale but rather to test the concepts for countries to build confidence. For some smaller population contexts, DaaS could meet the full population needs via a pilot, and provide flexibility later to probably migrate the system if needed to a different host.

Individual DPGs that are powering DaaS have their own sandboxes. Countries are free to reach out to them directly to experience their products before experiencing them through DaaS if so preferred.

Once the use case from a country is known, how long will it take for the "package" to be ready

The typical steps envisioned are:

1. Install the DPG solution

2. Integrate with the country specific workflow to enable the use case.

The goal is to have a DPG solution packaged to make the installation possible in less 8 hours and integration work between 1 to 3 weeks. During this time, the policy and pilot modalities are worked out in parallel. The current plan is to provide DPI service to the first user in T+4 weeks. T being the date when the country, svc provider and DPG owner kick off meeting after signing the MoU.

What "features" will the package have if you imagine a typical G2P use case

In the current release G2P Use case envisioned is only ID to Account Mapper. Beneficiary & Scheme Management platforms are not planned in this first phase scope. In an existing G2P flow, Mapper comes handy to pay to a beneficiary using a functional id.

If a svc provider (e.g Deloitte) is spending time/ effort packaging this, how will it become available to the competition? Or will this package belong to Deloitte and others will have to build their own?

DPGs are providing the installable package. Deloitte and another svc provider are consuming it as is. Deloitte is building tech support, proj mgmt unit (PMU) capacity and coordination with cloud svc providers as part of the DaaS initiative.

In future, Deloitte may add new features on open source offering and provide value added services to create a competitive landscape.

Does the IP of the package be with the DPG who can allow any other vendor to use it?

Yes, for the work done and put out by the DPG. For any custom packages (in future), Svc Providers may be encouraged to use open source licences but not mandatory. DPGs/Funders may enforce some of these policies.

What if the country wants to use some other private sector provider for the second use case of G2P payments (beyond the pilot)?

It is perfectly possible. It is up to the country to hand over the pilot work to the new private sector vendor or request to install a new instance.

Please note, underlying solutions picked in phase-1 Digital Auth, Digital Credentials, Mapper can be reused across depts / vendors, the same way that in India, Digi Locker credentials, Aadhaar, NPCI mapper is used by various DBT programs.

What is it?

Convert any database into a trusted reusable reference like health workers registry, farming land registry, skills registry and many more

Why Functional Registries?

What use cases can be powered?

Sunbird registries - Additional Resources:

Sunbird registries - Experience centre:

Demo link, user guide frontend and backend setup: https://rc.sunbird.org/reference-solutions-for-functional-registries/health-registries/organ-registries

Content of this site is licensed under CC BY-SA 4.0 by CDPI

Citation guidelines:

Centre for DPI. (2024). [Title of the Article]. DPI Wiki. Retrieved from https://docs.cdpi.dev/

For example:

Centre for DPI. (2024). Understanding DPI. DPI Wiki. Retrieved from https://docs.cdpi.dev/understanding-dpi

To be updated soon!

SDK - A software development kit (SDK) is a set of software tools and programs provided by hardware and software vendors that developers can use to build applications for specific platforms.

Please see the DaaS legal framework here

Q. What’s the overall legal framework of DaaS?

A. There are 4 parties involved in DaaS:

1. DaaS Country Partner - the Country department which is executing the DaaS package

2. DaaS DPG Partner - the DPG which is providing the DaaS product to be deployed in the country

3. Service Provider(s) - the entity(ies) that will deploy, maintain and provide the technical support during the pilot of DaaS

4. Advisor - the partner covering all advisory ( managerial, technical, legal etc)related to DaaS. For the first cohort, this will be the Centre for DPI.

These parties interact with each other in the following ways:

1. LoI or MOU between DaaS Country Partner and DaaS DPG Partner

2. Ecosystem Participation Terms signed by all SPs and DPGs part of the DaaS ecosystem

3. MOU or LoI between the DaaS Country Partner and the Advisor (optional)

Q. Why have ecosystem participation terms instead of bilateral contracts between the DPG and SP?

A. Bilateral contracts usually undergo lengthy negotiation processes before each signing and due to this, the terms agreed to by different DPGs and SPs would differ. Due to this, the countries would have no common bar on how to assess the offerings by the DPGs and the SP selection committee would have no common bar on how to judge the SPs bidding for a project. The goal of the EPT is to align all parties into basic foundational clauses such as cyber security, data portability, open source code etc. to adhere to the 'rapid deployment' and 'standardisation' goals of DaaS.

Q. Will SPs still need an additional bilateral contract to close on compensation and other details of implementation that cannot be standardised?

A. The 'contract' in this case is a multi-party contract termed as Ecosystem Participation Terms that lay out the general contracting clauses of any DaaS implementation. The country-specific implementation details are governed by the 'Country Scope Document' which is signed off on by the Country and DPG, and signed by the implementing SP - this also indicates the compensation amount, deliverables, payment schedules etc. which would typically be covered under a special contracting clause.

Q. When do EPT terms kick in?

A. The EPT comes into force only for the DPG and SP chosen for a particular implementation post the signing of the country scope document.

Q. Why does the MOU restrict Service Providers from using code under their own IP that is not available through open source?

A. The principle behind DaaS is standardisation and productization. This means that all the products available through the DaaS program must be exactly replicable and rapidly executable for multiple countries, hence it involves standard legal frameworks, product kits, funding amounts etc. If a service provider brings in their own proprietary code or IP into the execution cycle, multiple scenarios separate from the best practices of DaaS may play out:

1. The country may get locked-in to that particular service provider since a new vendor will not have access to that code or IP

2. It will prevent the country or DPG from switching service providers mid-way in case of any contingency

3. The same DaaS product if deployed in another country with another service provider will see a different execution with different features since the code will not be replicable and it will defeat the purpose of DaaS

Q. So can I as a Service Provider take the base-line open source product and pitch it to countries myself without DaaS?

A. Of course! In the initial cohorts of DaaS, the DPGs provide training and capacity building for service providers on their products. Once a service provider feels sufficiently empowered, they are free to approach countries directly and deploy the open source code on their own, enhanced by their own IP as they see fit.

Q. Why aren't cloud providers included in the EPT?

A. Cloud providers typically have back-to-back contractual agreements with the SP to support on country deployment. From a DaaS implementation perspective, we did not want to distribute the accountability among various participating entities so we restricted it to SPs who receive the compensation from the DPGs for implementation and are thus, responsible for its timely execution. Cloud providers would operate as an entity under the SPs.

However, similar to SPs, cloud providers are also empowered to individually utilise DaaS artefacts and open source DPG code to implement independently in countries.

What is it?

Access just in time, trusted information via Chatbot

Why AI Assistant?