# What is DPI? The term Digital Public Infrastructure (DPI) 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 and 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 represented by well-designed, population-scale infrastructure that abide by the [principles](/the-dpi-wiki/dpi-tech-architecture-principles) of the DPI approach. Examples include India's digital identity system *Aadhaar*, Brazil's payment system *Pix*, Estonia's data-sharing platform *X-Road*, Singapore’s national digital ID *SingPass*, Thailand’s instant payment system *PromptPay*, and Argentina’s *Mi Argentina* digital services platform. # DPI Overview An approach that works to transform nations at scale 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 and 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 technology innovation in recent memory - not the iPhone, not the laptop, not even the computer chip - has triggered as much subsequent innovation as those original open standards. Read that again slowly. So looking ahead, how can countries take a similar **approach** to catalyse inclusion and innovation in areas such as access to money, healthcare, education, and competitive innovation in services? The DPI approach is about moving from platforms to open networks powered by protocols. We think there are three (3) **foundational categories** that make up **21st-century digital public infrastructure:**
For more information on DPGs, please visit https://digitalpublicgoods.net/standard/
# What DPI can I build? Ideas to drive exponential socio-economic growth in your country based on your role ### What DPI can I build if I am a ... \ **Central Bank or Financial Regulator:** 1. Develop an eKYC policy to encourage use of digitally signed credentials under boundary conditions 2. Publish a modern Interoperable [QR Code](https://docs.cdpi.dev/technical-notes/digital-payment-networks/interoperable-qr-code) Standard for mobile payments 3. Upgrade to a modern and programmable payment protocol (P2P/P2M) allowing fintech to innovate on UX while keeping money flow with financial institutions 4. Craft an [Open Finance](https://docs.cdpi.dev/technical-notes/data-and-credentialing-infra) regulatory framework for [data sharing](https://sahamati.org.in/what-is-account-aggregator/), including publishing technical specifications for financial data sharing across sectors **Department with an ID** (National ID, tax ID, drivers license, birth certificate, etc): 1. Drive coverage of your [Digital ID](https://docs.cdpi.dev/technical-notes/digital-ids-and-electronic-registries/digital-id), using private enrollment partners, fewer fields, etc. 2. Add [Capabilities on your ID](https://docs.cdpi.dev/technical-notes/digital-ids-and-electronic-registries/digital-id/capabilities-on-id-system) to help it operate as a DPI in your society: 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:** 1. Publish a modern Interoperable [QR Code](https://docs.cdpi.dev/technical-notes/digital-payment-networks/interoperable-qr-code) Standard for mobile payments 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.) 3. Add an [ID to Account mapper](https://g2pconnect.cdpi.dev/protocol/interfaces/beneficiary-management/mapper-architecture) - a 4-field registry to allow government benefits across departments to be sent to any kind of account (mobile money, bank account, etc.) **Social Protection Benefit Program Manager:** 1. Use [face authentication](https://docs.cdpi.dev/technical-notes/digital-ids-and-electronic-registries/digital-id/face-authentication) or other existing ID authentication to ease onboarding and registration 2. Add an [ID to Account mapper](https://g2pconnect.cdpi.dev/protocol/interfaces/beneficiary-management/mapper-architecture) - a 4-field registry to allow gov’t benefits across departments to be sent to any kind of account (mobile money, bank account, etc.) 3. Leverage existing or encourage creation of [registries](https://g2pconnect.cdpi.dev/protocol/interfaces/registries) to check eligibility criteria automatically 4. Craft each block of your G2P ecosystem per open [specifications](https://g2pconnect.cdpi.dev/g2p-connect/readme) to create a plug and play G2P architecture and vendor flexibility **IT Authority/Digital Economy Ministry:** 1. Create an optional issuance module of [Verifiable credentials](https://docs.cdpi.dev/technical-notes/data-and-credentialing-infra/verifiable-credentials) (eLockers) to encourage other departments (state, local, central) to issue their certificates as credentials (the decision to convert paper-based docs into verifiable credentials remains with individual departments) 2. Encourage [eAuth/eKYC/eSign capabilities](https://docs.cdpi.dev/technical-notes/digital-ids-and-electronic-registries/digital-id/capabilities-on-id-system) for service delivery on existing functional IDs 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 government departments to move from single-window portals to open up their APIs to enhanced user experience and service delivery 5. Publish electronic standard for [consent](https://docs.cdpi.dev/technical-notes/electronic-signature-pki-and-trust-infra/econsent) to share data (to be used across domains) **Finance Ministry:** 1. Create an [Open Banking](https://docs.cdpi.dev/technical-notes/data-and-credentialing-infra) ([data sharing](https://sahamati.org.in/what-is-account-aggregator/) + payments) framework to allow individuals to share their data to get access to services (without systemic risks) 2. Encourage government departments to use an [ID to Account mapper](https://g2pconnect.cdpi.dev/protocol/interfaces/beneficiary-management/mapper-architecture) for disbursal of government benefits **Commerce/Digital Economy Ministry:** 1. Commerce: [Open discovery and fulfilment of services](https://docs.cdpi.dev/technical-notes/discovery-and-fulfillment-networks) to increase overall accessibility in sectors like digital commerce, mobility, logistics, and manufacturing. Allows any party to use any app to discover and avail any service available on any platform **Tax Authority:** 1. Open up APIs for tax filing to third parties to reduce failure rates and increase compliance. 2. Convert tax payment certificates to a [verifiable credential](https://docs.cdpi.dev/technical-notes/data-and-credentialing-infra/verifiable-credentials) (machine-readable & digitally signed) by adding a QR code [**Health Ministry/Authority (click here):**](https://cdpi.gitbook.io/dpi-for-healthcare/) 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)**](/initiatives/agri-connect-forthcoming) 1. Registries 2. Open networks for discovery and 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:** 1. [Verifiable credentials](https://docs.cdpi.dev/technical-notes/data-and-credentialing-infra/verifiable-credentials): Give user data back to patients in the form of machine-readable (phase 1), digitally signed, verifiable (phase 2) records to allow for portability and reuse of data **Private Employer:** 1. [Verifiable credentials](https://docs.cdpi.dev/technical-notes/data-and-credentialing-infra/verifiable-credentials): Issue salary slips and employment reports as machine-readable, digitally signed, verifiable records to allow for the reuse of data 2. Can integrate with ID Account Mapper to seamlessly process employee payrolls **If you are an individual:** 1. You can contribute to open-source projects 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.
# Inputs for designing a DPI informed digital transformation strategy 1 minute read: +1s to transform your digital strategy into a DPI strategy
| Existing Infrastructure | +1, Light touch intervention | Transforms into a DPI | Value Unlocked for Individuals and Institutions | General Recommendation |
| ID: Physical ID Card | Add a digitally signed QR code | Now capable of supporting eAuth, eKYC, and single-sign on | Private and public institutions are now able to verify the legitimacy of the card with high trust and low cost | Allow for multiple IDs that can be digitally verified for different types of proof (such as individual ID, business ID, tax ID etc) instead of trying to build one ID that would hold all that data |
| Payments: Individual wallet applications | Set out a common spec for QR codes | Makes all the wallets interoperable | Digital payments can now be made from any store of value to any store of value in secure formats | Keep the actual movement of money with the banks, with the fintechs only creating the user experience layer |
| Data Sharing: Any Paper-Based Certificate | Add a digitally signed QR code | Makes the paper-based document into a digitally verifiable credential | Private and public institutions are now able to verify the legitimacy of the document with high trust and low cost | Allows for synchronous and asynchronous data-sharing mechanisms for public and private data with regulatory oversight |
| General: Social Benefit Scheme | Include a G2P mapper to help route money | Now allows sending money to any ID number | Allows for choice in destination bank account and prevents leakages due to misrepresentation | Introduce the design of digital signatures and PKIs for future DPI builds Include an Open API policy to allow any department to leverage third-party interfaces to deliver better user experiences Publish a volunteer policy to leverage the capabilities of skilled individuals to close capacity gaps |
2. **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 fertilizers. 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.
3. **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 overhauling 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, eKYC, or single-sign on 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](https://docs.cdpi.dev/initiatives/dpi-as-a-packaged-solution-daas) 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](/initiatives/dpi-as-a-packaged-solution-daas/daas-in-a-nutshell) 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. # How much does it cost to build DPI? DPI does not have to be expensive to build! > 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](https://docs.cdpi.dev/references/home) 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](https://becknprotocol.io/)); 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 enrollment or 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](https://docs.cdpi.dev/initiatives/dpi-as-a-packaged-solution-daas) and receive support from private philanthropic sources and open source DPI packages necessary to roll-out these capabilities.
{% hint style="info" %} To view an indicative costing model that reflects the typical price ranges of a minimalist DPI execution by leveraging an open source product, irrespective of geography, please visit the [standardised artefacts page](/initiatives/dpi-as-a-packaged-solution-daas/reusable-daas-artefacts). The model 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. {% endhint %} # Is my system a DPI? 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](https://docs.cdpi.dev/the-dpi-wikipedia/dpi-tech-architecture-principles) principles.
# TL; DR - Is my system a DPI? A crisp, easy to consume summary of the previous article *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.*
- Craft a reciprocity policy that ensures that in order to access data from any other actor in the data sharing ecosystem, you must also provide data to the ecosystem.
- Craft a clear use case for a high value service that is improved based on access to data. For instance, for open banking, the use case is often improved lending portfolios, which can scale up based on access to data.
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. 2. **Adoption Layer**: Once the DPI has been built, it is only successful if it is 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, the 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. 3. **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 nationwide 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 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! # DPI and Privacy/Security **Question**: Does DPI reduce personal privacy, increase security risks, or hurt public safety by increasing the 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: * [x] **Minimalism in data capture -** The less data is captured, the less of a honeypot is created. * [x] **Avoiding tracking** - no collection of location/purpose in ID auth/eKYC * [x] Creating a **Virtual ID or a token as a fungible alias** for the permanent ID to avoid providing the actual ID number for services * [x] Authentication done with **consent** of the user (via one time password or biometrics) * [x] Usage **audits which are permanently auto-deleted** every n months * [x] **End-to-end encryption** for data at rest and data transport layers * [x] Allowing residents to **lock their ID and/or biometrics,** disabling authentication * [x] **Unique tokens that are different for every system**, eliminating the ability to merge databases * [x] **Multi-factor authentication** for high value transactions * [x] 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: * [x] **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. * [x] 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 * [x] Introducing a **detailed, granular consent** (purpose specific and data specific) artefact (digitally signed for added security) required from the individual to share data * [x] **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) * [x] A **pre-specified time period for access to data** - with consent revocable at any time by the individual * [x] **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. # DPI and the Digital Divide **Question**: Will DPI deepen the digital divide? **Short Answer**: No. 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 often misunderstood 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. | Has an email account and connectivity | Can generate email-based one-time password (OTP) | | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Mobile Device (feature phone or smartphone) with connectivity | Mobile-based OTP | | Mobile Device without connectivity | Offline XML authentication | | No mobile devices or connectivity | If verifier has a card reader: Smart Card authentication of a fingerprint stored on a chip (requires verifier to have a card reader) | | No mobile devices or connectivity | If verifier has a biometric reader: Fingerprint authentication with fingerprint reader | | A mobile device, but no connectivity and challenge with fingers/fingerprints |
If verifier has phone: Face authentication
If verifier has biometric reader: Iris authentication with iris scanner
| | No devices, no connectivity, challenge with fingerprints/iris | Demographic field authentication via a digitally signed QR code on a paper or plastic-based ID card | \ Similarly, when we speak about interoperable digital payments as DPI, they are not limited to those with access to digital devices: | Payers in urban areas with access to smartphones and connectivity | Make payments (P2P, P2M) by scanning a QR code via their smartphone or entering a financial address through any mobile application | | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Street vendors in urban areas without smartphones | Instead of purchasing an expensive credit or debit card reader to accept payments, they can simply print a QR code on a piece of paper to accept digital payments | | Payers in rural or semi-urban areas with feature phones but no internet connectivity |They can use USSD to send an SMS text message (e.g. using a specific number like \*99#) as a payment instruction to transfer funds to anyone using mobile networks
They can also initiate payments as above to interoperable offline wallets or mobile money accounts to transact without messaging core banking systems
| | Rural areas with no phones or connectivity | They can use their biometrics (such as a fingerprint) to authorise payment transactions through any local vendor | | Local languages / illiterate / cannot see clearly | They can call a number and speak in their local language. An AI-enabled service can translate their instructions into a payment instruction and carry out the transaction using the standard DPI rails on their behalf after receiving authorisation. | Well-designed DPI is suited to 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. # Identity & Trust Infrastructure Who is the counterparty? Can I trust them? Verifying identity and accessing profile data of people, entities, and 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: that is, 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 at least one 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 driver’s licenses) should also strive to make their profile data accessible via APIs or 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 accessible through 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, facial, etc.) * eKYC * Single Sign-On * Civil/Functional Registries * Entity Registries * Object Registries (land, etc.) # Digital ID Many countries have built Digital IDs, including Singapore (Singpass), Rwanda’s national ID with eKYC, Chile’s national ID and India's Digital ID (Aadhaar). ### Context The government’s primary goal is to reach its target user base efficiently, identify users easily, and deliver public services, such as medical care, pensions, tax collection and more. **Every country can relate to the existence of at least one of the following identity systems**: 1. National Registration Cards (NRC) 2. Regional Government Identity Cards 3. Registrations using one or more biometric modalities (fingerprint, iris, face, voice, etc.), which may or may not have used for deduplication or uniqueness checks 4. Foundational identities such as civil birth and death records, national IDs, etc. 5. Purpose-driven functional identities such as voter IDs, driver’s licenses, farmer registrations, tax IDs, or professional licenses (doctor, lawyer, teacher, etc.) 6. Foundational/Functional IDs restricted to certain categories of users (for example, citizens above a certain age, residents, refugees, etc.) **In most of the countries foundational or functional IDs are ****issued**** as**: 1. Simple paper documents, optionally with a photo and/or hologram sticker 2. Laminated paper-based ID 3. PVC cards 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, 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 government services. However, governments are **challenged to accept** foundational or functional IDs for various reasons: 1. Distinguishing genuine from fraudulent ID cards 2. Trusting scanned QR code contents 3. Procuring large numbers 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 GOVERNMENTS TO DRIVE DIGITAL INCLUSION VIA UNIVERSALLY ACCEPTED AND TRUSTED CREDENTIALS.** ### 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 the ID MUST be digitally signed by the issuing authority, and verification of the digital signature must be possible to prove non-repudiability. Human verification of a QR code can be made possible using QR Code reader applications and SDKs. 3. **Online/Offline Accessible**: Digital ID MUST be accessible through online APIs and offline through digital wallets or digitally signed QR codes. 4. **Online/Offline Authentication**: Digital ID MUST be able to authenticate the user in both online and offline modes. In offline mode, authentication service points are able to verify users in regions with low or no network coverage while maintaining trust. 5. **Consented Use**: Digital ID SHOULD enable mechanisms for users to provide consent from the ID holder during authentication, data access, or other uses of the ID. 6. **Privacy Protecting**: Digital ID SHOULD allow masking or partial disclosure of data where full ID is not required and ensure necessary consented authorisation for data access. 7. **Self/Assisted Use Cases**: Digital ID SHOULD enable both self-service and use cases to access, verify and authenticate the user with appropriate consents. The use of authorised operators helps reach digitally illiterate users and helps in inclusion via open APIs with necessary authorisation from the ID holder. 8. **Enable Full/Selective KYC Disclosure**: Digital ID SHALL enable option to release either full or selective Know Your Customer (KYC) attributes for authorised downstream use of ID. 9. **Unique ID**: Digital ID MAY be deduplicated against biometric or demographic data to ensure ONLY unique IDs are issued. However, uniqueness of an ID is NOT a necessary requirement. Many use cases do not require identifying and authenticating a unique user. Identifying and easily/securely authenticating a user is sufficient. 10. **Laws/Regulations**: Digital ID MAY be governed by local laws and regulations to ensure equitable access for ecosystem participants across sectors, thereby reducing friction and costs. Laws/regulations ensure the acceptance of DIGITAL IDs with the properties outlined above, creating a multiplier effect as a foundational Digital Public Infrastructure. ### Why is Digital ID important? Many government programs do not require a unique ID to deliver services; only a few do. The use of Digital IDs enables policymakers to reduce friction and cost; and allow integration between systems. By using Digital IDs, policymakers can integrate with other jurisdiction functional IDs. Identifying duplicates through trusted demographic data techniques represents a continuous improvement process aimed at eliminating ghost beneficiaries. Digital IDs made available from existing functional ID systems can eventually be linked to deduplicated foundational IDs when a country adopts such a deduplicated issuance platform. While a biometric deduplicated ID system is considered a foolproof 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 the following indicative suggestions as an inspiration to convert physical IDs to Digital IDs: 1. The government should enable issuance and use of PKI certificates in accordance with 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 cleanup to improve the quality and standardization of data formats should be taken up during this phase. 1. A recent high-quality photo and/or verified mobile number should be part of the ID database/registry. 2. These two key ID attributes will enable robust verification and authentication capabilities. The ID authority should procure PKI certificates to issue Online Digital IDs through Auth/eKYC APIs and Offline Digital IDs through mobile wallet and eLocker applications. The ID authority should enable government and private ecosystem players to access Digital ID through APIs, self/assisted use, acceptance of digitally signed docs, cybersecurity and 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 can scale nationally to become a national ID only when it remains 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 provides a yes/no response upon verification request. * e-KYC is a feature that submits foundational profile fields in addition to authentication. * Single Sign-On (SSO) 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 authentication feature would be most useful, as it enables other government departments to verify an individual’s identity before providing services. For example, a social benefits department can authenticate whether an applicant is a registered farmer before processing benefit transfers. For ***national IDs*** (such as minor ID, passport, non-resident ID), e-Auth or SSO may be built. For the ***national foundational ID***, any 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 accessing benefits through a government portal. **IMPORTANT NOTES:** 1. EACH COUNTRY MUST DEVELOP ITS OWN STRATEGY TO MAKE FOUNDATIONAL AND 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 A MUST-HAVE DIGITAL PUBLIC INFRASTRUCTURE (DPI) FOR ANY DIGITAL TRANSFORMATION JOURNEY! ## Attributions # Capabilities on ID system How to convert any ID system into a DPI Building a use cases layer on top of any foundational / functional ID system is crucial for unlocking service delivery. An ID system should be considered infrastructure that provides citizens with 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, as outlined below, can make an existing ID system operate as digital public infrastructure in an economy, thereby enhancing both enrollment rates and overall system utilization.
| Technical Layer | Governance Layer | Market Layer |
|---|---|---|
a) Using open specification/standard APIs allow interoperability between data-issuing authorities and any data-consuming authorities b) Embed online/offline machine-readable and digitally signed QR codes on all physical documents c) Digitally sign all documents issued online, this can be done by a department on behalf of multiple agencies, by departments or private entities. d) Allow verifiable credentials to be available through eLockers or Wallets. | a) Specify a consent artefact that articulates to the individual what data they are consenting to share, for what purpose, with whom, for how long, and methods to revoke consent b) Self-Regulatory Organizations (SROs) of market players can be set up to monitor user-facing applications dealing with consent. All applications must be data-blind (they cannot access any data, the data-fetch happens behind the scenes, and they are simply for user experience) | a) Allow for multiple applications to be built that cater to different sections of society based on region, language, purpose, etc. |
Further reading: S[unbird Registry and Credentials ](https://docs.sunbirdrc.dev/learn/readme) and [DIVOC verifiable credentials ](https://divoc.digit.org/platform/verifiable-credential-vc-production-deployment)
# Decision Framework for Verifiable Credentials When governments come to us with questions about Verifiable Credentials, they rarely start with technology. They start with a problem — a border crossing that needs to work offline, an agricultural export certificate that takes weeks to verify, a health credential that must protect patient privacy across jurisdictions. This framework answers the questions our operations team hears most often from countries implementing digital public infrastructure: * **Which standard fits my use case?** * **Which open-source DPG platform do you recommend?** * **How do these systems interoperate across countries?** We mapped 12 real-world use cases — from national ID and education to agriculture traceability, and tourism against the six dominant VC standards and four Digital Public Good platforms: **INJI**, **CREDEBL**, **walt.id**, and **QuarkID**. *** ### Resources #### 🗂️ Standards by Use Case An interactive reference covering all 13 use cases. Each card shows the recommended standards, the reasoning behind them, and the key technical and regulatory requirements — with indicators for privacy, interoperability, adoption maturity, and offline capability. [View Standards by Use Case](https://vc-use-cases.cdpi.dev/) *** #### 📊 VC Stack Comparison A detailed technical comparison of INJI, CREDEBL, walt.id, and QuarkID across standards support, credential formats, revocation, offline verification, DID methods, and interoperability. [View VC Stack Comparison](/technical-notes/data-and-credentialing-infra/verifiable-credentials/decision-framework-for-verifiable-credentials/comparative-analysis-of-verifiable-credential-stacks) *** #### 📄 Decision Cheatsheet A single-page printable reference. Includes the full DPG × Use Case matrix, the six standards at a glance, critical interoperability gaps, and a quick-guide for platform selection. [View Cheatsheet](https://vc-use-cases.cdpi.dev/vc-cheatsheet.html) # Comparative Analysis of Verifiable Credential Stacks ### Objective The primary goal of this comparison is to highlight the unique strengths, technical capabilities, and architectural philosophies of each stack. By analyzing how these platforms handle data, connectivity, and trust, this document aims to guide stakeholders in choosing the solution that best fits their specific use cases—whether those involve government-grade offline identity, enterprise-scale multi-tenancy, or broad European ecosystem compliance. ### Neutrality and Pro Bono Disclaimer This comparative analysis is conducted on a **pro bono** basis by the Centre for Digital Public Infrastructure. We maintain a **tech-neutral** stance and have not received any financial compensation or "kickbacks" from the analyzed technology providers. Our goal is to support countries in their digital transformation journey, regardless of the specific technology stack they choose to implement. ### Selection of Themes The technical and operational dimensions explored in this document are not exhaustive. Instead, they represent the **most common themes and challenges** that arise during our country-level consultations. These dimensions were selected to address the specific needs of stakeholders looking for government-grade identity, enterprise scalability, or regulatory compliance. ### Document Structure The analysis is organized into key technical and operational dimensions: * **Standards & Data Formats**: An overview of the protocols (e.g., OpenID4VC, W3C) and data structures (e.g., JWT, SD-JWT, mDoc) supported by each provider. * **Revocation & Security**: An examination of the mechanisms used to invalidate or manage the status of credentials in production environments. * **Infrastructure & Deployment**: A look at **Multi-Tenancy** capabilities, distinguishing between stacks designed for single-use deployments and those built for scalable SaaS platforms. * **Operational Connectivity**: A deep dive into **Offline Verification**, assessing how each stack utilizes technologies like BLE, NFC. * **Trust Anchors**: A comparison of **DID Methods and Blockchain** integrations, ranging from ledger-agnostic web approaches to native Hyperledger Indy or Polygon support. * **Hosting Options and Licensing:** A look at all implementation models and Licences. * **Documentation Quality & Sustainability:** Examination of the accessibility of technical guides and the long-term viability. * **Security, Privacy & Compliance:** how the stacks adhere to security-by-design, cryptographic standards, and regulatory frameworks. ### Assessment Baseline (Version Scope) | Stack | Version | | ------- | ---------------------------------- | | INJI | Wallet: Mobile (0.21) / Web (0.15) | | CREDEBL | 2.1 | | walt.id | Jan 2026 Release | | QuarkID | Protocol v2.2 | ### How to Read this Document Each section includes a Feature Matrix that uses the following visual indicators to allow a quick at-a-glance comparison across stacks: ✅ Full support ⚠️ Partial / In progress ❌ Not supported ### 1. Standards Support **What is it?** These are the technical rules that allow wallets to communicate with each other. **Importance** It ensures interoperability. Without common standards, a user with a wallet from one provider couldn't present their credentials to a verifier using another provider
| Feature | INJI | CREDEBL | walt.id | QuarkID |
|---|---|---|---|---|
| W3C VC Data Model 1.1 | ✅ | ✅ | ✅ | ✅ |
W3C VC Data Model 2.0 CREDEBL via roadmap; QuarkID partial | ✅ | ⚠️ | ✅ | ⚠️ |
OpenID4VCI Inji Draft 13; walt.id Draft 11 & 13 | ✅ | ✅ | ✅ | ✅ |
OpenID4VP Inji Draft 23; walt.id Draft 14 & 20 | ✅ | ✅ | ✅ | ✅ |
| IETF SD-JWT VC | ✅ | ✅ | ✅ | ✅ |
ISO 18013-5 (mDL/mDoc) Inji & CREDEBL in progress; walt.id full | ⚠️ | ⚠️ | ✅ | ❌ |
| ISO 18013-7 | ❌ | ❌ | ✅ | ❌ |
DIDComm v2 CREDEBL via Aries; QuarkID native | ❌ | ✅ | ❌ | ✅ |
| SIOPv2 | ❌ | ❌ | ⚠️ | ✅ |
| Hyperledger AnonCreds | ❌ | ✅ | ❌ | ❌ |
eIDAS 2.0 / EUID ARF walt.id only - full alignment | ❌ | ❌ | ✅ | ❌ |
| EBSI / ESSIF | ❌ | ❌ | ✅ | ❌ |
| DIF Presentation Exchange | ⚠️ | ✅ | ✅ | ⚠️ |
| Trust over IP (ToIP) | ❌ | ✅ | ❌ | ❌ |
| Feature | INJI | CREDEBL | walt.id | QuarkID |
|---|---|---|---|---|
| JSON-LD with Linked Data Proofs | ✅ | ✅ | ✅ | ✅ |
| JWT (JWS) | ✅ | ✅ | ✅ | ✅ |
| SD-JWT | ✅ | ✅ | ✅ | ✅ |
| ISO mDoc (CBOR / 18013-5) | ⚠️ | ⚠️ | ✅ | ❌ |
| AnonCreds / ZKP-CL | ❌ | ✅ | ❌ | ❌ |
| ZKP (other - BBS+ / etc.) | ❌ | ❌ | ❌ | ✅ |
| Ed25519 | ✅ | ✅ | ✅ | ✅ |
| secp256k1 / secp256r1 | ✅ | ✅ | ✅ | ⚠️ |
| RSA | ✅ | ❌ | ✅ | ❌ |
| Decentralized Web Nodes (DWN) | ❌ | ❌ | ❌ | ✅ |
| Feature | INJI | CREDEBL | walt.id | QuarkID |
|---|---|---|---|---|
Bitstring Status List (v1.0) Inji experimental | ⚠️ | ✅ | ✅ | ✅ |
StatusList2021 (W3C) Inji JSON-LD only | ⚠️ | ✅ | ✅ | ❌ |
| RevocationList2020 | ❌ | ❌ | ✅ | ❌ |
IETF Token Status List CREDEBL for SD-JWT & ISO mDoc | ❌ | ✅ | ✅ | ❌ |
AnonCreds tails + accumulators CREDEBL production-ready | ❌ | ✅ | ❌ | ❌ |
| On-chain revocation registry | ❌ | ✅ | ❌ | ✅ |
| Suspension (separate purpose) | ❌ | ❌ | ✅ | ⚠️ |
| Custom status reasons via policy | ❌ | ❌ | ✅ | ⚠️ |
| Self-hosted API endpoint | ✅ | ✅ | ✅ | ✅ |
| Feature | INJI | CREDEBL | walt.id | QuarkID |
|---|---|---|---|---|
Full multi-tenant architecture walt.id Enterprise Stack only | ❌ | ✅ | ⚠️ | ✅ |
| Shared agents (multi-tenant) | ❌ | ✅ | ⚠️ | ✅ |
| Dedicated agents (single-tenant) | ✅ | ✅ | ✅ | ✅ |
| Tenant-specific configurations | ❌ | ✅ | ⚠️ | ✅ |
| White-labeling / sub-accounts | ❌ | ❌ | ⚠️ | ✅ |
| Designed for SaaS deployments | ❌ | ✅ | ⚠️ | ✅ |
| Agent-agnostic architecture | ❌ | ✅ | ⚠️ | ❌ |
National-scale deployment support Inji & CREDEBL proven at national scale | ✅ | ✅ | ❌ | ⚠️ |
| Feature | INJI | CREDEBL | walt.id | QuarkID |
|---|---|---|---|---|
BLE (Bluetooth Low Energy) Inji via Tuvali protocol | ✅ | ❌ | ⚠️ | ✅ |
| NFC | ❌ | ❌ | ✅ | ❌ |
| Wi-Fi Aware (mDL) | ❌ | ❌ | ✅ | ❌ |
| QR Code offline verification | ✅ | ✅ | ✅ | ✅ |
PixelPass QR compression Inji exclusive | ✅ | ❌ | ❌ | ❌ |
Offline face authentication Inji exclusive | ✅ | ❌ | ❌ | ❌ |
| AnonCreds offline predicates | ❌ | ✅ | ❌ | ❌ |
| Status list caching | ❌ | ❌ | ✅ | ⚠️ |
| Works without internet | ✅ | ❌ | ⚠️ | ✅ |
| Feature | INJI | CREDEBL | walt.id | QuarkID |
|---|---|---|---|---|
| did:web | ✅ | ✅ | ✅ | ✅ |
| did:key | ✅ | ✅ | ✅ | ✅ |
| did:jwk | ✅ | ❌ | ✅ | ❌ |
| did:peer | ❌ | ✅ | ❌ | ✅ |
| did:indy (Hyperledger Indy) | ❌ | ✅ | ❌ | ❌ |
| did:ebsi (EBSI/ESSIF) | ❌ | ❌ | ✅ | ❌ |
| did:cheqd | ❌ | ❌ | ✅ | ❌ |
| Polygon blockchain | ❌ | ✅ | ⚠️ | ✅ |
zkSync Era / Rootstock / ETH QuarkID multichain EVM | ❌ | ❌ | ❌ | ✅ |
X.509 Certificate Trust Anchoring CREDEBL: Trust Chain & Trust Registry | ❌ | ✅ | ⚠️ | ❌ |
| Ecosystem Governance framework CREDEBL: incl. IATA Travel PoC | ❌ | ✅ | ⚠️ | ⚠️ |
| Ledger-agnostic / custom VDR | ✅ | ✅ | ✅ | ❌ |
| No blockchain dependency | ✅ | ❌ | ✅ | ❌ |
| Feature | INJI | CREDEBL | walt.id | QuarkID |
|---|---|---|---|---|
| Cloud deployment | ✅ | ✅ | ✅ | ✅ |
| On-premise deployment | ✅ | ✅ | ✅ | ✅ |
Sovereign cloud support walt.id places specific emphasis | ⚠️ | ⚠️ | ✅ | ⚠️ |
| MIT License | ✅ | ❌ | ❌ | ❌ |
| Apache 2.0 License | ❌ | ✅ | ✅ | ✅ |
| Enterprise edition available | ❌ | ⚠️ | ✅ | ⚠️ |
Foundation-backed MOSIP & Linux Foundation respectively | ✅ | ✅ | ❌ | ❌ |
| Feature | INJI | CREDEBL | walt.id | QuarkID |
|---|---|---|---|---|
| Extensive developer documentation | ✅ | ⚠️ | ✅ | ⚠️ |
| API reference docs | ✅ | ✅ | ✅ | ⚠️ |
| Quickstart / sandbox guides | ✅ | ⚠️ | ✅ | ❌ |
| Active developer community | ✅ | ✅ | ✅ | ⚠️ |
Foundation / institutional backing MOSIP & Linux Foundation | ✅ | ✅ | ❌ | ⚠️ |
| Regular release cadence | ✅ | ✅ | ✅ | ⚠️ |
| Open roadmap published | ⚠️ | ⚠️ | ✅ | ❌ |
| Feature | INJI | CREDEBL | walt.id | QuarkID |
|---|---|---|---|---|
| Security-by-design principles | ✅ | ✅ | ✅ | ✅ |
| Key management infrastructure | ⚠️ | ⚠️ | ✅ | ⚠️ |
| Auditability / audit trails | ⚠️ | ⚠️ | ✅ | ⚠️ |
| GDPR-aligned design | ⚠️ | ✅ | ✅ | ⚠️ |
| eIDAS 2.0 compliance-ready | ❌ | ❌ | ✅ | ❌ |
| ZKP / selective disclosure | ❌ | ✅ | ⚠️ | ✅ |
| Hardware security module (HSM) | ❌ | ⚠️ | ✅ | ❌ |
Biometric authentication Inji offline face auth | ✅ | ❌ | ❌ | ❌ |
Govt-grade hardening (out-of-box) All stacks require implementer hardening | ⚠️ | ⚠️ | ⚠️ | ⚠️ |
# Building Data Analytics Pipelines Imagine you’re a technical analyst or decision-maker wanting to better understand and predict regional migration flows. To do 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 was asked by an international cooperation agency. Here are some insights from that exchange that can apply 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 Cleansing: 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. An open-source tool we often ask countries to reference is [Obsrv](https://obsrv.sunbird.org/), by Sunbird, which processes up to 2 billion events per day at peak. It’s built to operate with the highest levels of reliability with bare minimum operations effort at scale. 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 (Extract, Transform, Load) 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. # Data Exchanges: System to system data sharing ### Section 1: The Core Concept: From Silos to Seamless Flows In many nations, service delivery is paralyzed by **data silos** — isolated databases that do not communicate. This fragmentation forces citizens to act as data couriers, physically transporting certificates to prove their identity or eligibility. Government departments, lacking secure rails, often resort to haphazard sharing via unencrypted emails or manual exports, creating significant security risks. Meanwhile, the private sector is forced into redundant data collection and storage, as they lack secure access to even non-sensitive government data. **A data exchange — which in practice may comprise multiple complementary building blocks and components — provides a standardised, secure protocol for system-to-system data sharing**. By enabling secure, point-to-point communication between disparate systems without centralising storage, it facilitates the seamless and standardised data flows necessary for modern governance. **While often viewed as a government-to-government tool, it truly matures into digital public infrastructure when the private sector can leverage the same rails to innovate and deliver integrated services based on consented access to personal data**. Implementations like Estonia's X-Road (saving 800+ years of working time annually), India's API Setu (4,200+ APIs), Singapore's APEX (connecting the whole-of-government API ecosystem), and Uganda's UGHub (connecting 150+ public and private entities) demonstrate that secure, high-scale exchanges are viable across diverse economic contexts. This note addresses system-to-system sharing of personal data. It does not cover open data publication, anonymised datasets, or aggregate statistics — which involve different design choices and governance requirements. # Data Exchange 101 The components below are not all required from day one — they reflect the full anatomy of a mature exchange, and a country should adopt them progressively as use cases and scale demand. #### Components A data exchange platform is typically composed of the following functional layers: ***Data sharing layer:*** * **API gateway.** The API gateway is the runtime proxy — the entry point for every call. It intercepts requests, enforces authentication and rate limiting, routes traffic to the correct backend, and returns responses. It is the operational core of the platform. * **Key manager.** The key manager determines whether a consumer is who they claim to be and whether they are authorised to make a specific call. * **Traffic manager.** The traffic manager enforces rate limits and throttling across the gateway. It prevents any single consumer from overwhelming the platform and ensures fair allocation of capacity across all participants. * **Micro integrator.** The micro integrator handles protocol transformation and payload orchestration — translating between REST and SOAP, aggregating responses from multiple backends, and mediating between systems that speak different technical languages. A mature exchange must support both synchronous request-response patterns and event-driven patterns — publish/subscribe, webhooks, and message queues. A civil registration event pushing updates to health, education, and social welfare systems is far more efficient than each consumer polling for changes. Both patterns are necessary. ***Trust and security layer:*** * **Payload signing.** Payload signing provides cryptographic proof that message content was not altered in transit and that it came from the holder of a specific signing key. It gives integrity — the content is unchanged — and authenticity — it came from the key holder. It is distinct from encryption: encryption prevents third parties from reading data, while signing lets a verifier attribute the message to its signer. Payload signing is a prerequisite for non-repudiation but not sufficient on its own. * **Audit log.** The audit log records every data access event — who requested what, when, and what was returned. For regulatory compliance and accountability, this log must be tamper-evident. In centralised platforms, logs are held by the operator. In distributed architectures, logs are held independently by both parties. In event-driven architectures, the log must also capture what events fired, what downstream systems were notified, and whether they acknowledged receipt. * **Encryption.** Ensures data in transit cannot be read by third parties. In practice this means TLS on every API call between consumer, platform, and backend. A stronger variant, mutual TLS (mTLS), requires both parties to present certificates. Distinct from payload signing — encryption prevents reading; signing prevents tampering. * **Non-repudiation**. Non-repudiation provides legally binding proof that a specific party sent a specific message and that the recipient received it. It has two components. Non-repudiation of origin requires the signing key to be bound to a vetted identity through a trust infrastructure — a PKI/CA hierarchy, or a decentralised equivalent such as DIDs anchored to a trust registry — and the signature to be trust-timestamped by an independent authority. Non-repudiation of receipt requires a signed acknowledgement from the recipient. Together these ensure neither party can credibly deny what was sent, when, or that it was received. ***Governance and discovery layer:*** * **Developer portal.** The developer portal is where consumers discover available APIs, read documentation, test in a sandbox environment, and subscribe to the services they need. It is the outward-facing interface of the platform. * **Service registry.** The service registry is the machine-readable catalogue of all APIs and data schemas available on the platform. It is foundational to cross-agency interoperability — without a common registry, agencies cannot discover each other's services. * **Consent manager.** The consent manager handles citizen authorisation for data sharing, capturing, storing and exposing machine-readable consent artefacts (consent receipts) that the gateway can verify at request time before any call involving personal data proceeds. In event-driven exchanges, consent must be verified at the point of subscription. * **Analytics.** Analytics provides real-time visibility into platform health, usage patterns, and per-consumer breakdowns. ***Legacy connectivity layer:*** Legacy connectivity components — sidecar proxies and database adapters — allow systems that were never designed to share data to be exposed as modern APIs without replacing the underlying infrastructure.
Exhibit 1: Components of a data exchange platform (centralised model)
#### A note on X-Road and distributed architectures The component model above reflects a centralised architecture — the model followed by API Setu, APEX, and UGHub. X-Road, Estonia's national data exchange layer, follows a different topology but retains the same underlying functions. In X-Road, there is no central gateway. Instead, each participating organisation operates a ‘Security Server’ — a local node that handles routing, encryption, payload signing, and audit logging on that organisation's behalf. The functions do not disappear; they are redistributed to the edge. What remains central in X-Road is narrow: a Central Server that distributes the global configuration — the trust anchors, the list of approved external Certification Authorities (CAs) and Timestamping Authorities (TSAs), and the registry of members and their Security Servers. The CAs that issue participant certificates and the TSAs that timestamp messages are external trust services, not the Central Server itself. This is what makes the network trusted without requiring a central data broker. # Platform Approaches: Four Examples 1 The table below compares four national data exchange implementations across key technical dimensions. These are not competing standards; they represent different points on a spectrum, each reflecting a distinct set of choices about where trust is enforced, how participants are onboarded, and how much operational burden is placed on individual agencies. A country selecting or evolving its own approach should read this less as a ranking and more as a map of tradeoffs.| Component | India - API Setu | Singapore - APEX | Estonia - X-Road | Uganda - UGHub (WSO2) |
Publisher / Control plane Where API providers design, version, configure and publish APIs | Yes — ministries upload OpenAPI 3.0 specs via the API Setu’s API Studio. | Yes — agencies publish and manage APIs via APEX’s API Lifecycle Portal. | Yes — Security Server configuration. Each member manages its own Security Server, registering services with the Central Server. | Yes — WSO2 API Manager Publisher portal. NITA-U centrally governs; MDAs publish their own APIs through the platform. |
| Data sharing layer | ||||
API Gateway Runtime proxy that intercepts calls, applies policies, and routes to backend | Yes — APIs hosted on API Setu's infrastructure are proxied. APIs merely listed bypass the gateway. | Yes — central gateway for all Singapore government APIs. | No — peer-to-peer. Data flows directly between Security Servers. No central proxy. | Yes — WSO2 API Manager. All APIs proxied through NITA-U's deployment in the government data centre. |
Key manager Issues and validates credentials; controls who can access what | Validates OAuth token on every request. Identity verification at registration is manual. | Token anchored to Corppass or TechPass — a government-verified legal entity. Runtime token traceable to a verified organisation. | Certificates issued by a trusted CA at ecosystem join. Every request is signed with that certificate — identity is cryptographically bound to every message. | Validates OAuth tokens via WSO2 Identity Server. Supports eKYC. Better identity anchoring, but dependent on NITA-U's IAM configuration. |
Traffic manager Enforces rate limits and throttling across the gateway | Yes — rate limiting enforced at the Envoy layer for hosted APIs. | Yes — rate limiting enforced per agency and per API. | Not applicable. No central gateway. Each Security Server manages its own capacity. | Yes — WSO2 Traffic Manager enforces throttling policies centrally. |
Micro integrator Transforms payloads, orchestrates multiple backend calls, protocol mediation | No — neither synchronous orchestration nor event-driven patterns supported at the platform layer. Both are the consumer's responsibility. | No — both patterns must be handled at the application layer by the consuming agency. | No — X-Road is a transport and trust layer only. | Yes — WSO2 Micro Integrator handles synchronous orchestration. WSO2 Streaming Integrator adds event-driven capability. |
| Trust and security layer | ||||
Payload signing Cryptographic proof that message content was not altered in transit | Not present — standard OAuth bearer tokens carry no payload integrity guarantee or authenticity guarantee | Built-in and enforced platform-wide. Self-signed JWTs ensure every call is tamper-proof and replay-proof. | Architectural and mandatory. Every message is signed by the sending Security Server and timestamped. Legally non-repudiable. | Manual configuration only. Not enforced platform-wide. |
Audit logs Record of who called what and when | Yes — Operator held. | Yes — Operator held. | Yes — distributed. Logs held independently by both data provider and consumer. Tamper-evident by design. | Yes — Operator held. |
Encryption in transit Data is encrypted between caller and server so it cannot be read by third parties Plaintext exposure Point where data is decrypted and briefly exists unencrypted | TLS only — standard HTTPS between consumer and API Setu endpoint. At the API Setu gateway — decrypted on arrival, re-encrypted before forwarding to ministry backend. | TLS with identity anchored to Corppass/TechPass. Mutual TLS available. At the APEX gateway — same exposure model as API Setu. | TLS between Security Servers. Data decrypted and re-encrypted at each hop. At each Security Server only. No central broker — exposure limited to the two communicating parties. | TLS standard. WSO2 supports mutual TLS configurable per API. At the WSO2 gateway in the government data centre. |
Non repudiation Legally binding proof that a specific party sent a specific message and that the recipient received it | Not present. No payload signing, no trust infrastructure binding, no trust timestamping, no signed receipts. | Partial — non-repudiation of origin is partially supported. JWT signing provides authenticity but key binding to a vetted legal entity via CA hierarchy is not enforced platform-wide. No signed receipts for non-repudiation of receipt. | Full non-repudiation. Origin: signing keys are certificate-bound to vetted legal entities via RIA's CA, and every message is trust-timestamped by an independent TSA. Receipt: Security Servers exchange signed acknowledgements. | Not present by default. WSO2 supports PKI-based signing and can be configured for trust-timestamping, but neither is enforced platform-wide. |
| Governance and discovery layer | ||||
Developer portal Where consumers discover APIs, read docs, test in sandbox and subscribe | Yes — browse by ministry, sector, use case. One registration to subscribe; each API requires publisher approval. | Yes — Lifecycle Portal. Subscription workflow and sandbox. Identity anchored to Corppass/TechPass. | No built-in portal. Ecosystems layer a separate catalogue (e.g. RIHA in Estonia). Discovery requires bilateral agreement before data moves. | Yes — WSO2 Developer Portal. Entities browse, subscribe, and test via Try-it-out console (where configured by the API publisher). Governed by NITA-U. |
| Service registry | Yes — APIs listed by ministry and sector. Browsable via the developer portal. Consistency depends on ministry compliance with OpenAPI 3.0 standards | Yes — central registry maintained by GovTech. Standards enforced centrally. | Yes — maintained by the Central Server. Lists all member organisations and their security servers; individual service descriptions are held locally on each secuirty server. | Yes — WSO2 API Manager maintains a central registry. NITA-U governs what is published. |
| Consent Manager | Partial — DigiLocker flow requires explicit citizen consent via OAuth authorization code for Aadhaar-linked data. No uniform platform-level consent layer; consent implementation varies by API publisher | Not built into the platform. Consent handled at application level. | Not architectural. Estonia's data tracker allows citizens to see who accessed their data after the fact. Consent management layered separately for specific sectors. | Not built into the platform. Consent handled at application level. |
Analytics Tracks API usage, latency, errors, per-consumer breakdowns | Yes — usage dashboards. Publisher-level analytics available. | Yes — real-time monitoring, anomaly detection, unified dashboard managed by GovTech. | Limited — local logs at each Security Server. No central analytics dashboard. | Yes — WSO2 Analytics provides usage reporting. NITA-U holds centralised analytics. |
a protocol which is agnostic ...
... powers payments which are interoperable!
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"
Traditional approach of 'digitisation' breeds exclusion
The DPI approach guarantees inclusion + market participation
First-order effects on the ecosystem
Second-order effects on the country's overall growth
| No | Scenario | Remarks |
|---|---|---|
| 1 | Initiation Modes | Scan & Pay, Click & Pay, Deep Linking |
| 2 | Initiation Locations | Terminals, POS, Online, ATM |
| 3 | Static / Dynamic QRs | |
| 4 | P2M & P2P use cases | |
| 5 | Subscripitons / Recurring Payments | Fixed amount e.g., Rentals, Equity/MF SIPs, EMIs, Subscriptions, etc., |
| 6 | Bill Payments | Varying amount e.g., Utilities |
| 7 | IPO Payments | |
| 8 | Refunds | |
| 9 | Buy Now Pay Later | |
| 10 | Step Up/Down Payments |
# Cash-in Cash-Out (CICO) Interoperable banking agents and devices for last-mile CICO transactions ### 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 conducting online bank transfers or even checking their balance. Moreover, many local businesses need physical cash and do not see much value in digital payments. The old adage reads: Banks cannot go to every village; it is simply not possible. While banks may not be able to establish physical branches in villages, through the Digital Public Infrastructure approach, banking services 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 the challenge of last-mile access to formal banking services. ### What: The cash-in cash-out system equips selected 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: This process involves securely transferring benefits to end beneficiaries by removing intermediaries and removing friction and costs. Cash-Out: This process provides access to physical cash at the last mile, enabling the use of 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, national identity number, and biometrics to authenticate that information. Using this, the micro-ATM can access 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, the system can accurately connect to bank servers, find the match, and retrieve that data for the individual to use. Once again, by providing authentication through their biometrics, individuals can: 1. Deposit cash 2. Withdraw cash (remember, the Micro-ATM operator carries 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 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 banks is that it allows expansion of the society into the formal financial sector, allowing access to 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. \
# G2P Payments Increasing Efficiency of Government-to-Person Payments In their daily operations, governments across local, state and national levels make various payments to citizens. These 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 for 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](https://drive.google.com/file/d/1flSxkL9u5WLqo4Qw4mh_jRN6-bgAa8TN/view) is about building an overarching architecture as a simple +1 step to your existing systems that ensures interoperability, inclusion, privacy, security, autonomy, and asynchronous adoption by design.
There are 4 key building blocks to the DPI approach in solving for G2P
This approach has enabled the Government of India to rapidly connect with their population of over 1 billion people
Key Learnings of the G2P Blueprint
# Cloud-Agnostic Deployment of DPI and Data Portability ### Executive Summary Cloud-agnostic architecture is not merely a technical preference but a strategic imperative for DPI implementations. As infrastructure-as-code and one-click deployment patterns mature, the ability to deploy, migrate, and operate DPI systems across multiple cloud providers or on-premises infrastructure becomes both technically feasible and operationally prudent. ### The Strategic Case for Cloud Agnosticism #### Sovereign Control, Economic Flexibility, and Risk Mitigation Digital Public Infrastructure demands architectural decisions that preserve **sovereignty**, maintain **economic flexibility**, and mitigate **concentration risk**. Cloud-agnostic design ensures that country authorities retain the benefits of cloud speed and flexibility whilst preserving the ability to: * **Migrate workloads** across providers without wholesale re-architecture, reducing switching costs when better alternatives emerge * **Negotiate from strength** with cloud service providers, leveraging competitive pricing and avoiding cost escalation from vendor lock-in * **Maintain operational continuity** independent of any single vendor's business decisions, outages, or security incidents * **Respond to geopolitical and regulatory shifts** that may affect cloud service availability, without disruption to essential services * **Adopt hybrid strategies** that optimize cost-performance ratios across providers and on-premises infrastructure * **Evolve incrementally** — adopt new technologies without forced wholesale migration # Architectural Principles for Cloud-Agnostic DPI The following principles guide cloud-agnostic DPI architecture. For each principle, we identify the open standards and frameworks that enable portable implementation.
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-based (capex) to **outcome (opex) based costing**, allowing organisations to pay per user rather than for each input cost. 6. Can help **tackle incumbency issues** to demonstrate proof of concept as a convincing argument. 7. **Provides the flexibility to engage one or more service providers simultaneously.** 8. **Choice of clouds and portability.** 9. **Achieve scale and speed** to de-risk churn and changes within the system. # Funded DaaS Program overview Deploy DPI in your country by competitively applying for the Funded DaaS Program 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 rollout for higher chances of success.
| CATEGORY | USE CASES (given by DPG) |
|---|---|
| Agriculture | Single sign-on with digital ID for farmers to access the Government Portal to place bulk sell orders. |
| Education | University students authentication to download course digital certificates. |
| Govt. Services | Profile data sharing for citizens applying for a driving license with age verification. |
| Govt. Services | Profile data sharing for citizens applying for Voter ID with age verification. |
| Govt. Services | Single sign-on for registering online police complaints. |
| G2P Benefits | Authentication for citizens availing flood relief kits or drought relief items from government-run stores. |
| G2P Benefits | Authentication for farmers applying for bank loan waiver or claiming crop insurance relief. |
| G2P Benefits | Auth for citizens availing subsidized Food grains from Government run stores/ godowns. |
| Healthcare | Authentication for patient registration at hospitals. |
| Financial Inclusion | eKYC using digital ID for citizens applying for online bank account opening. |
| Climate | Issuing carbon credits as verifiable credentials for energy market trading, eligibility for subsidies, etc. |
| Education | Students having their education certificates and admission letters as verifiable credentials and sharing them with prospective employers, loan providers, and scholarship programs |
| Healthcare | Citizens holding their vaccination details as verifiable credential to demonstrate eligibility for entering public spaces. |
| Healthcare | Healthcare professionals with VCs of their professional licensing can present them to enable practice anywhere. |
| Govt Services | Passports as verifiable credentials to assist people in their easy commute through airports. |
| Govt Services | Business owners holding trade licenses as verifiable credentials gain access to credit facilities. |
| Govt Services | Citizens having their civic certificates, including marriage licenses, voter ID, social security information, passports, and driving licenses, as verifiable credentials to be presented as required. |
| CATEGORY | USE CASES |
|---|---|
| Agriculture | Direct benefit transfer to farmers for fertiliser subsidies |
| Healthcare | Ministry of health sending childbirth allowance for pregnant women |
| Education | Merit-based tuition fee reimbursement for children from low-income groups |
| Climate | Energy subsidies for houses with rooftop solar |
| Social welfare | Direct benefit transfer for vulnerable sections after a natural disaster |
| Enables implementation of decentralised and interoperable registries |
| Machine-readable, digitally signed, and openly accessible via APIs |
| Configurable schema to capture minimal & contextual information |
| Enables ease of data updates by the end user |
| Claim and attestation workflows to maintain trustworthy data |
| Easily verifiable by third-party systems through external attestation and allows easy interoperability with existing systems |
| Discoverable registry records with control on public, private, and personal information |
| Registries, in addition to providing data about entities they are designed for, also enable verification and authentication of the entities |
| Ability to audit changes in registry records |
| Healthcare | A Healthcare Professional Registry that maintains comprehensive records of all health professionals, including doctors and nurses, ensuring registration and verification. This registry provides citizens with access to verified and authentic professionals. |
| Healthcare | A Health Facility Registry where medical institutions are cataloged, enabling patients to find nearby facilities with the services they need, assured of their quality and authenticity. |
| Agriculture | A Farm/Land Registry that catalogs agricultural properties to support sustainable land use planning and facilitate subsidy allocation. |
| Healthcare | An Organ Registry system including Pledge Registry, Recipient Registry, and Donor Registry that matches donors with recipients, streamlining organ transplantation processes and saving lives. |
| Government Services | A Government Scheme Registry that connects all eligible citizens with all the welfare programs and schemes run by the government |
| Education | Educational Registries: Parents searching for accredited educational institutions in their area for their child and being able to compare the programs, ratings, and facilities offered by each. |
| Education | A Student Registry that tracks academic progress, facilitating scholarship opportunities for students. |
| CATEGORY | USE CASES |
|---|---|
| Agriculture | A farmer obtaining information about multiple government schemes and programs. |
| Climate | A citizen obtaining information about how to reduce their carbon footprint and various associated subsidies. |
| Education | A parent receiving assistance with handling their child with special needs. |
| Education | A teacher receiving assistance with using a new teaching technique in her class. |
| Education | A student receiving assistance on how to apply for various higher education options and scholarships available to her |
| Healthcare | A healthcare professional obtaining information on government protocols for preventing a new virus |
| Justice and social welfare | A social worker receiving suggestions on how she can help a victim of specific type of domestic violence |
# Country x DPG MOU /LoI FAQs Please see the DaaS legal framework [here ](https://docs.google.com/document/d/1WjoUDT0IB9Jcel5eyA1q0279UJj_cYmhLxlFJE9hsv4/edit?pli=1\&tab=t.0#heading=h.k552y4umgrjn) 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, whether cloud-based or on-premises, 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-premises locally hosted DPI? A. No, it doesn’t. The choice of hosting the DPI, whether private cloud, public cloud, on-premises, 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 or 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 standardised the language in order to help in scale. Due to this, the standard language for the 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 the legal basis for the DaaS engagement and will 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 for open source software, including communications on sunset versions, backward compatibility upgrades for supported community versions, and community connections. This helps 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. Instead, funds are routed through the DPGs to DPG-trained and implementing service partners. In the 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 select implementation partners. They can quickly deploy DPI pilots to demonstrate proof of concept and proof of success within their own contexts. Post the pilot phase, countries are expected to identify long-term service partners as per countries processes. 4. DaaS is about packaging policy, procurement, core product software, pre-built and configured solutions, and training resources. This MoU serves as a template to expedite rollout while maintaining an appropriate balance between speed and the protection of a country's independence and sovereignty. 5. In the current design, Service Providers have a back-to-back agreement with DPGs to ensure all obligations are delivered through them. This arrangement keeps all 3 parties (country, DPG, and service provider) 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? A. The country owns the implementation. The data resides in servers , either on-premises or on cloud, which are directly and completely 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 grants permission for a specific purpose and duration, and only 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, 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 minimal collateral damage and, when appropriate, 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 and 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.
# Ecosystem Participation Terms FAQs Please see the DaaS legal framework [here](https://docs.google.com/document/d/1WjoUDT0IB9Jcel5eyA1q0279UJj_cYmhLxlFJE9hsv4/edit?pli=1\&tab=t.0#heading=h.k552y4umgrjn) 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 matters related to DaaS, including managerial, technical, and legal aspects. 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 that are 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, and other elements 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.\ \
# DPI Residents Program To be updated soon! # Agri Connect (forthcoming) # Glossary **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. # Curated Specifications Reference Links ## 1. Overview Centre for Digital Public Infrastructure (CDPI) curates open standards and specifications across various categories of DPIs for easy reference. This is an initiative to curate specifications that follow [DPI principles](/the-dpi-wiki/dpi-tech-architecture-principles) to enable countries to create required Digital Public Infrastructure rails. This list includes open specifications that are published by non-profit global institutions or agreed upon based on a global governance, as well as de-facto standards used by countries where the specifications have reached a scale of over 10 million transactions. **Note:** 1. This is a draft and all stakeholders in DPI space can share their comments. 2. Reference implementations listed here are provided as per the claim of implementing organisations. CDPI has not verified these claims. 3. Countries are advised to independently verify at the time of the adoption. ## 2. Identifier & Registries ### 2.1 Auth & eKYC 1. OAuth - [specs](https://www.rfc-editor.org/rfc/rfc6749) 2. Open ID - [specs](https://openid.net/developers/) 3. SAML - [specs](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html) ## 3. Signatures & Consent ### 3.1 eSign 1. PKCS #10 - [standard](https://datatracker.ietf.org/doc/html/rfc2986) ### 3.2 Digital Data Sharing Consents 1. Electronic Consent artefact (Ministry of IT, India) - [spec](https://dla.gov.in/sites/default/files/pdf/MeitY-Consent-Tech-Framework%20v1.1.pdf) 2. Consent building block (Govstack) - [docs](https://govstack.gitbook.io/bb-consent/) | [specs](https://github.com/GovStackWorkingGroup/bb-consent) ## 4. Payments ### 4.1 G2P, P2P & P2M Payments 1. G2P Connect - [docs](https://g2pconnect.cdpi.dev/g2p-connect/readme) | [specs](https://g2p-connect.github.io/specs/) 2. P2P / P2M - Unified Payments Interface Protocol (forthcoming) 3. UK Open Banking Payments - [specs](https://standards.openbanking.org.uk/api-specifications/) 4. ISO 20022 messaging standards [docs](https://www.iso20022.org/iso-20022-message-definitions?business-domain=1) | specs #### 4.1.1 Reference Implementations 1. Batch payments - [Mojaloop](https://docs.mojaloop.io/getting-started/), [Mifos](https://mifos.org/resources/documentation/) 2. Beneficiary / Scheme Mgmt partners - [OpenG2P](https://docs.openg2p.org/guides/developer-guides), [OpenSPP](https://docs.openspp.org/index.html), [DIGIT](https://core.digit.org/) 3. Cash In Cash Out (CICO) - AePS [specs](https://www.npci.org.in/PDF/AePS/MicroATM_Standards_v1.5.1_Clean.pdf?TSPD_101_R0=08f002952bab20008b7d8da5fd1e2eab2b05707bcf97d4d8a37e2e70559f1e5cf52cf371b2dd168808262911fb14300061acdcd788119a546d34e72dd804f44c2e3b50502dbe0deab71add6e66931a3c1c3f7d06c44de06e493ae71639d420a0) published by NPCI/IBA/UIDAI ## 5. Data & Open AI/ML Models ### 5.1 Verifiable Credentials Issuance 1. W3C compliant issuance [standard](https://www.w3.org/TR/vc-data-model/) | implementation [guide](https://www.w3.org/TR/vc-imp-guide/) | draft issuance api [specs](https://w3c-ccg.github.io/vc-api/) 2. ISO/MDL 3. G2P Connect issuance [docs](https://g2pconnect.cdpi.dev/protocol/interfaces/credentialing) | specs #### **5.1.1 Reference Specs/Implementations:** 1. Sunbird VC issuance [docs](https://docs.sunbirdrc.dev/learn/readme) | [specs](https://github.com/Sunbird-RC/sunbird-rc-core/tree/main/api-documentation) 2. Inji by MOSIP [docs](https://docs.mosip.io/inji/) | specs 3. CREDEBL (Self-Sovereign Identity (SSI) & Verifiable Credentials (VCs)) [docs](https://docs.credebl.id/en/intro/what-is-credebl/) | [specs](https://github.com/credebl) ### 5.2 Verifiable Credentials - Presentation 1. W3C compliant presentation standard | Implementation [guide](https://www.w3.org/TR/vc-imp-guide/) #### 5.2.1 Reference Specs/Implementations: 1. Credential Schemas: Sunbird VC [specs](https://github.com/VC-Specs/vc-specs) | [schemas](https://docs.google.com/spreadsheets/d/1y4z1X7Dfercj7C3wkKbPAR_ExHbL_KgXbwtFzeFK078/edit#gid=1454655977) (draft) 2. EU digital identity wallet [docs](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/arf.md) | [specs](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework) ### 5.3 Consented Data Sharing 1. X-Road [docs](https://docs.x-road.global/)| [specs](https://github.com/nordic-institute/X-Road) 2. Account Aggregator (Financial data sharing) [specs](https://github.com/Sahamati/account-aggregator-standards) ### 5.4 Datasets 1. ML data sets to train for local languages [docs](https://bhashini.gov.in/ulca/model/benchmark-datasets) | specs ## 6. Discovery & Fulfilment ### 6.1 eCommerce Network 1. Beckn Protocol - [docs](https://becknprotocol.io/) | [specs](https://github.com/beckn/protocol-specifications) ### 6.2 Education 1. Sunbird - [docs](https://sunbird.org/product/building-blocks) | specs 2. BeckN DSEP - docs | [specs](https://github.com/beckn/DSEP-Specification) ### 6.3 Healthcare 1. BeckN Decentralised Health Protocol - DHP [docs](https://developers.becknprotocol.io/docs/introduction/introduction/) | [specs](https://github.com/dhp-project/DHP-Specs) 2. Health Claims Exchange - HCX [docs](https://docs.hcxprotocol.io) | [specs](https://github.com/hcx-project/hcx-specs) 3. Data exchange * Consent-based data exchange: DEPA [docs](https://depa.world) | [specs](https://github.com/iSPIRT/DEPA/blob/main/depa_2.0.yaml) * X-Road [docs](https://docs.x-road.global/)| [specs](https://github.com/nordic-institute/X-Road) 4. Data schema/ standards- [docs](http://www.hl7.org/fhir/documentation.html) 5. Information management systems (individual, hospital, community levels) * OpenMRS - [docs](https://wiki.openmrs.org/) | [specs](https://github.com/OpenMRS) * DHIS2 -[ docs](https://dhis2.org/about/) * OpenEHR - [docs](https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html#_architecture_overview) | [specs](https://openehr.atlassian.net/jira/projects) * OpenELIS - [docs](http://docs.openelis-global.org/en/latest/) | [specs](https://github.com/I-TECH-UW/OpenELIS-Global-2/) 6. Vaccination certificate (Verifiable credential): DIVOC [docs](https://divoc.digit.org/) | [specs](https://github.com/egovernments/DIVOC) ### 6.4 Social Networks 1. Open social network (Decentralized Social Networking Protocol) [docs](https://dsnp.org/introducing-dsnp.html) | [specs](https://spec.dsnp.org/) # Licensing 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
# DPI: Un resumen Una metodología comprobada para transformar naciones a escala **Infraestructura Pública Digital** - o DPI - es un término al que se refieren con frecuencia funcionarios de gobiernos, think tanks, instituciones de desarrollo, organizaciones sin ánimo de lucro y directores ejecutivos de todo el mundo como un **enfoque transformador** para dar un salto hacia el desarrollo a gran escala. Países como Brasil, India, Singapur, Australia y Tailandia han desarrollado y ampliado sus DPI. Como sucede con cualquier concepto en constante evolución, cada nuevo proyecto y experimento en todo el mundo modifica el significado del término. En el Centro de DPI nos gustaría ayudar a los países a responder a la siguiente pregunta: ¿cuál es esa fórmula mágica que llaman DPI, y cómo puede acelerar nuestros planes nacionales de digitalización para crear **economías digitales innovadoras e inclusivas?** {% file src="/files/VLEuBrYvZY4oIZ20n2Cq" %}