# Centre for Digital Public Infrastructure (CDPI)

> CDPI is a global advisory centre housed at IIIT Bangalore that provides software-neutral technical architecture guidance to countries building population-scale digital public infrastructure (DPI) — spanning identity, payments, data sharing, credentials, and discovery networks. It operates across 40+ countries with 12 active pilots.

Source: https://cdpi.dev | Wiki: https://docs.cdpi.dev | Contact: info@cdpi.dev

---

## About the DPI Wiki

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

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

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

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

---

## What is DPI?

Digital Public Infrastructure is employed in two primary contexts:

1. As a Strategic Approach: "an approach to addressing socio-economic problems at population scale" that merges "open technology standards with robust governance frameworks" to stimulate both private and community-driven solutions. This methodology targets widespread societal challenges including financial access, healthcare affordability, educational quality, environmental sustainability, and legal system accessibility.

2. As Implemented Systems: The term also refers to functioning, large-scale systems that embody DPI principles. Notable real-world examples include:
   - India's Aadhaar (digital identity)
   - Brazil's Pix (payment infrastructure)
   - Estonia's X-Road (data-sharing platform)
   - Singapore's SingPass (national digital identification)
   - Thailand's PromptPay (instant payment mechanism)
   - Argentina's Mi Argentina (digital services delivery platform)

---

## DPI Overview

Digital Public Infrastructure (DPI) is a phrase now regularly referenced by government officials, think tanks, development institutions, nonprofits, and even global CEOs as a transformational approach to accelerate progress at scale. Countries like Brazil, India, Singapore, Australia, and Thailand have all built and scaled DPI.

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.

The DPI approach is about moving from platforms to open networks powered by protocols. There are five foundational categories that make up 21st-century digital public infrastructure:

1. Identifiers and registries
2. Data sharing and AI/ML models
3. Trust infrastructure (signatures and consent)
4. Discovery and fulfilment
5. Payments

These categories are not mutually exclusive. Payments is a type of data sharing. Digital signatures are used across ID, Payments, Data, and Discovery. These categories indicate areas to focus on when crafting DPI.

The blocks can only be considered as DPI if they are built in accordance with the technical architecture principles. A data sharing system that is not interoperable, or a digital ID that is not minimalist or reusable, cannot be considered as digital public infrastructure.

Examples of how DPI blocks supercharge interactions:

1. Identity Verification: With consent, any entity can verify identity through e-Authentication ("Are you who you claim to be?") and collect basic information through e-KYC ("Can you provide more details about yourself?"). This reduces costs for services such as banking and insurance.

2. Payments: Anyone can make digital payments to anyone, including street vendors, by scanning an interoperable QR code. This helps convert a cash-based economy to a digital economy. Integration of digital identity and payment systems allows governments to distribute social benefits without leakages.

3. Data Sharing: Enables verification of certificates and licenses by scanning digitally signed QR codes. Facilitates real-time, consent-based data sharing between systems, reducing the cost of services like lending. Also includes creation of publicly accessible datasets via open APIs.

4. Trust Infrastructure: Enables individuals to interact and transact without being physically present or using paper, using digital signatures and PKI.

5. Discovery and Fulfilment: Allows any product or service to be discovered and fulfilled across multiple applications — discovering a lawyer, booking telemedicine, choosing transport, or searching for scholarships.

DPI creates ecosystems combining: the right technology architecture, governance frameworks that are transparent, accountable, and participatory, and robust public and private market innovation.

---

## DPI Tech Architecture Principles

Five core technology architecture principles distinguish DPI from conventional digitization:

1. Interoperability
2. Minimalist, reusable building blocks
3. Diverse, inclusive innovation by the ecosystem
4. Federated and decentralised design
5. Security & privacy by design

These principles help DPIs achieve societal outcomes such as inclusion, user choice, innovation, scale of delivery, speed of services, public trust, competition in markets, and others.

### Interoperability

What to aim for: Accelerate network effects to drive innovation and competition through technological specifications, protocols and standards that enable interoperability across multiple actors. Prevent silos, fragmentation, monopolisation, and walled gardens by design.

How to achieve it: Published protocols, standards and specifications for the ecosystem to adopt and comply with.

Why it matters: Choice of solutions for individuals, scale of access and adoption, competition in markets while remaining interoperable, innovation by market players.

### Minimalist & Reusable Building Blocks

What to aim for: Unbundle problems and solutions into core, modular, minimalist, and reusable building blocks with open protocols. These should create high trust and low costs when re-used. The ecosystem can combine these to create many solutions (akin to lego blocks). Minimalism and modularity allow each block to be extensible as future technologies evolve.

This ensures simplicity, low cost/risk, ease of scalability, higher innovation, evolvability, and avoids hard-coding monolithic full-stack solutions. Maximalism creates complexity, high risk, low innovation, cannot deal with future advancements, and drives exclusion.

How to achieve it: Design minimalist components, protocols and specifications that do NOT form a complete solution but perform one function well. DPI architects should not overspecify data fields, forms of data, modes of use, types of authentication, etc.

Why it matters: Feasibility and success, privacy, combinatorial innovation, user-centric solutions, financial sustainability, evolvability and extensibility.

### Diverse, Inclusive Innovation

What to aim for: DPI should enable diverse innovation by public and/or private ecosystem users. Technical architecture should allow others to build solutions using DPI at scale via tools such as open APIs. A digital back-end shouldn't presuppose a single digital front-end. Enable multi-modal access: online, semi-online, and offline; self-service and assisted; smartphone, feature phone, and no-phone modes.

Public- and private-sector adoption and innovation should be voluntary and demand-based rather than mandated.

How to achieve it: Open APIs, digital signatures (PKI), digitally signed QR codes (offline), machine readability, reusable SDKs, data standards, multi-modal access.

Why it matters: Inclusion, scale, user choice, resilience, user-centric solutions.

### Federated & Decentralised by Design

What to aim for: Avoid centralisation. Allow for federated databases and systems where possible. This prevents honeypots (cybersecurity risk) and over-aggregation of information (privacy risk). It is perfectly possible to connect systems via common protocols and achieve unification without centralisation.

Any central system becomes a honeypot targeted by multiple cyber attacks. Decentralised systems function as lower value targets and are highly secure with very low chances of large scale data leaks.

How to achieve it: "Wrapper" APIs above disparate existing systems rather than new large centralised databases.

Why it matters: Autonomy of institutions, cybersecurity, individual privacy, resilience.

### Security & Privacy By Design

What to aim for:
1. Architecture operating on optimal ignorance: each system should know as little as possible
2. High auditability and traceability via digitally signed data, non-repudiable change logs, and authenticated transaction trails
3. Build and leverage participant registries as independent building blocks
4. Adopt verifiable credentials to increase trust
5. Enable structured, granular, and auditable consent artifacts
6. Multiple factors of authentication/authorisation

How to achieve it: Tokenisation & masking, granular electronic consent, end-to-end encryption, digital signatures, verifiable credentials.

Why it matters: Trusted usage of DPI by individuals and entities, cybersecurity and reduced surface area of attacks.

---

## DPI Implementation & Execution Guidance

21 key principles for rapid DPI implementation:

1. Frame the problem clearly. Identify real needs, not just absence of growth in a digital program.
2. Think through why existing ecosystem players act the way they do. Map current incentives and costs.
3. Don't aim for perfection before beginning. Start with a 'coalition of the willing'. Asynchronous adoption is par for the course.
4. Don't leave all of the 'how' to technology vendors. Think through blueprints including interoperability standards.
5. Small improvements (+1) Thinking. Ask what small changes across existing systems can convert them to DPI.
6. Small teams, high ownership. DPI execution requires small teams that drive actions across an ecosystem.
7. Design for system failures. Treat power outages, misaligned incentives, and connectivity gaps as expected.
8. Design architecture for tomorrow, implement use cases for today.
9. Frame adoption arguments from the counterparty's point of view, not the DPI builder's.
10. Parallel rather than consecutive phasing. Build building blocks in parallel.
11. Multiple bets for the first DPI block. Pick 3 potential use cases and 3 first adopters.
12. Test and debug early. No digital project is perfect on day 1. Target 40-50% coverage through design, then iterate.
13. Leverage existing digital assets and/or global open source where possible.
14. Impatient with actions, but patient with results.
15. Be prepared to act fast in policy windows.
16. Don't charge on day 1. Let adoption scale before adding cost.
17. Establish a volunteer policy.
18. Early market feedback and co-creation via hackathons and consultations.
19. Don't underestimate governance. Best tech must be supported by strong governance from the start.
20. Minimise your role. Focus on doing one thing well.
21. Expect a rocky road. Work with challengers, wait for incumbents.

---

## DPG and DPI

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

Not all Digital Public Goods can be used as building blocks for DPI. DPI can be built through open-source or private solutions, as long as they adhere to open specifications, generate network effects, and trigger innovation.

A stack of interoperable and scalable DPGs can come together to build DPI infrastructure, such as through G2P Connect for social benefit programs. OpenG2P, OpenSPP, CoreMIS for government benefits, and MOSIP for identity are examples of DPGs used to build DPI.

DPI can also be built without DPGs or any open source, though it may require more time, money, and expertise. Governments can use proprietary software and private vendors, as long as they follow principles of minimalism, interoperability, federation, inclusion, privacy, and security.

Even with proprietary software, countries should use open specifications (e.g., ISO standards for payments, G2P Connect specifications for service delivery) to ensure interoperability and avoid vendor lock-in.

Countries that build from scratch should always review available open source and ask vendors to ensure all best-practice features are incorporated.

---

## What DPI Can I Build?

### Central Bank or Financial Regulator:
1. Develop eKYC policy for digitally signed credentials
2. Publish interoperable QR Code Standard for mobile payments
3. Upgrade to modern programmable payment protocol (P2P/P2M)
4. Craft Open Finance regulatory framework for data sharing

### Department with an ID:
1. Drive Digital ID coverage using private enrollment partners and fewer fields
2. Add capabilities: eKYC, eAuth, eSign, Single Sign-On

### Payment Switch Operator:
1. Publish interoperable QR Code Standard
2. Upgrade to modern programmable payment protocol
3. Add ID to Account mapper for government benefits routing

### Social Protection Benefit Program Manager:
1. Use face authentication for onboarding
2. Add ID to Account mapper
3. Leverage existing registries for eligibility checking
4. Design G2P ecosystem per open specifications

### IT Authority/Digital Economy Ministry:
1. Create verifiable credentials issuance module (eLockers)
2. Encourage eAuth/eKYC/eSign on functional IDs
3. Publish open API policy for departments
4. Publish electronic consent standard for data sharing

### Finance Ministry:
1. Create Open Banking framework (data sharing + payments)
2. Encourage ID to Account mapper for government benefits

### Commerce/Digital Economy Ministry:
1. Open discovery and fulfilment of services across sectors

### Tax Authority:
1. Open APIs for tax filing to reduce failure rates
2. Convert tax certificates to verifiable credentials

### Health Ministry/Authority:
1. Registries (Professionals, Facilities, Drugs) with open APIs
2. Virtual Health Address linking health records
3. Open claims network for insurance
4. Open Health Network for telemedicine and services

### Supreme Court/Justice Department:
1. Open discovery of lawyers and services
2. Open APIs for case filing and tracking
3. Anonymised access to legal counsel

### Agriculture Ministry:
1. Registries
2. Open networks for discovery and fulfillment

### Private Bank:
1. Use open banking framework for creditworthiness assessment

### Private Hospital:
1. Issue verifiable credentials for patient records

### Private Employer:
1. Issue salary slips as verifiable credentials
2. Integrate with ID Account Mapper for payrolls

### Individual:
1. Contribute to open-source DPI projects
2. Contact CDPI for DPI work in finance, justice, energy, agriculture, healthcare

---

## First Use Case for DPI

Choosing the right first use case is critical for establishing proof of concept and proof of success. Three questions to answer:

1. Is it regularly used by individuals as a 'toothbrush' use? Or addressing a big-enough pain point? Select use-cases addressing daily needs. Uber launched in most emerging economies with Mercedes cars — the first impression matters.

2. Does it cover large amounts of the population? The larger the coverage, the faster the voluntary adoption.

3. Is the line ministry aligned with the DPI approach? Having agency or approval of the relevant ministry gives you a winning formula.

Note: The first use-case is different from first adopter. Example: DPI block = data sharing, first use case = bank certificates, first adopter = a digital lender.

While implementing the first DPI block, always pick three potential use cases and three first adopters to pursue in parallel.

---

## How Much Does It Cost to Build DPI?

Building DPI requires deep conviction and not deep pockets.

Minimal-cost approaches: Standards adoption and ecosystem orchestration (data sharing, discovery, payments) can be completed in 3-4 weeks with negligible government implementation expenses.

Two implementation paths:
1. Greenfield construction: New systems from scratch, multi-million dollar investments plus ongoing maintenance. Payment systems typically under $7 million initially.
2. Rapid upgrades: Enhance existing infrastructure. Substantially cheaper — potentially hundreds of thousands of dollars.

Conversion-based building blocks (verifiable credentials, identity authentication): approximately $750,000 (±15%) over six months for scaled implementation on existing systems. Expanding across 12 months to demonstrate multi-domain impact costs around $1.3 million (±15%).

Countries can leverage the DaaS Program for philanthropic support and open-source packages.

---

## Inputs for Designing a DPI-Informed Digital Transformation Strategy

Countries can transform existing digital infrastructure into DPI with light-touch +1 interventions:

- Physical ID Card → Add digitally signed QR code → Enables eAuth, eKYC, SSO
- Individual wallet applications → Set common QR code spec → Makes wallets interoperable
- Paper-based certificate → Add digitally signed QR code → Becomes verifiable credential
- Social benefit scheme → Include G2P mapper → Enables sending money to any ID number

Three tips for converting digitisation to DPI strategy:
1. Focus on quick-wins alongside larger digital transformation strategy
2. Asynchronous adoption through proof of value, rather than multi-department coordination
3. Build on existing infrastructure rather than from scratch

Countries should avoid blind duplication. Knowledge must be adapted to each country's unique context. The balance between standardised elements and contextualised program architecture must be achieved.

---

## Is My System a DPI?

Not everything labeled as DPI truly functions as such. Key principles:
- Open source does not automatically mean DPI
- DPI must use open APIs, open standards, and open specifications
- All DPI is designed to be reusable by third-party institutions
- Every DPI must adhere to five key technical design principles

DPI maturity is a spectrum, not a binary classification.

### Digital ID System as DPI
Must have an ID authentication layer returning yes/no answers. Should support multiple authentication modes (online API, mobile OTP, offline QR, biometrics). Mature systems enable eKYC, SSO, and e-signing.

### Registries as DPI
Must store data in machine-readable, digitally signed format accessible by external parties. Enable verifiable credentials and/or system-to-system access via open APIs.

### Digital Payments as DPI
P2P/P2M: Must be inclusive (majority of population), interoperable across accounts, apps, devices, channels, and recipient types. Architecture should be future-proof and extensible.

G2P: Must utilize reusable infrastructure — registries, ID-Account mapper, and CICO standards. Presence of digitised G2P does not automatically imply DPI.

### Data Sharing - Personal
Verifiable credentials must be digitally signed, machine-readable, and shareable with anyone. Real-time data sharing should use federated, open networks with user consent.

### Data Sharing - Anonymised
Must be available in machine-consumable format with APIs. Not PDFs or Excel files in bulk.

### Unifying Government Services
DPI approach: each department opens its APIs for third parties to consume. Not a centralised Enterprise Services Bus.

---

## Building a SuperApp: A Three-Step Guide

A SuperApp in government context is a one-stop portal providing access to multiple government services. It is NOT Digital Public Infrastructure by itself.

However, a SuperApp built on strong DPI (verifiable digital identity, data sharing, trust infrastructure, open APIs, payment rails) has much greater chance of succeeding.

DPI principles to enable SuperApp success:
1. Micro-services architecture: Unbundle into modular components communicating via APIs
2. Federated architecture: Data remains with original department, preventing honeypots
3. Layered Ecosystem Design: Open infrastructure layer, individual agency service layer, citizen-choice application layer
4. User control and inclusiveness: Multiple authentication methods, not just one
5. Private innovation: Open APIs to private sector and civil society

---

## Technical Notes — Identifiers & Registries

Verifying identity and accessing profile data is a crucial foundational function. When moving from physical to digital, establishing trust in identity is the first challenge.

A country should have multiple identities for multiple purposes, but at least one should provide foundational authentication capability and return commonly required data fields via an open API.

Building blocks in this category:
- Authentication (mobile, offline QR, biometric, facial)
- eKYC
- Single Sign-On
- Civil/Functional Registries
- Entity Registries
- Object Registries (land, etc.)

### Digital ID

Any foundational or functional ID supporting these properties is a Digital ID:
1. Human/System Readable (QR Code format)
2. Verifiable (digitally signed by issuing authority)
3. Online/Offline Accessible
4. Online/Offline Authentication
5. Consented Use
6. Privacy Protecting (masking, partial disclosure)
7. Self/Assisted Use Cases
8. Full/Selective KYC Disclosure
9. Unique ID (optional — uniqueness is NOT always required)
10. Laws/Regulations

How to convert existing ID to Digital ID:
1. Enable PKI certificates
2. Digitise existing registry data
3. Cleanup and add recent photo and/or mobile number
4. Procure PKI certificates for online/offline Digital IDs
5. Enable ecosystem access through APIs and policies

Merging multiple ID cards is not necessary. A foundational ID scales nationally when it remains minimalist (5-7 data points) and delivers value through reusability (eAuth, eKYC).

### Capabilities on ID System

An ID system is only as powerful as the use cases it can unlock. Building use case layers on top of any ID system makes it operate as DPI, enhancing enrollment rates and utilization.

### ID Authentication

The most powerful application of any identifier is electronic authentication across a digital economy. ID authentication verifies identity using an ID number combined with authentication factors, returning a Yes/No response.

Modes of authentication:
1. Demographic (name, address, date of birth)
2. Biometric (fingerprints, iris)
3. Face authentication
4. One-time password (OTP)

Authentication should be evaluated across three dimensions:
- Proof: document, identity, presence, or existence
- Self and assisted channels
- Offline and online modes

Challenges & workarounds:
1. Hard infrastructure: Offer offline, mobile-first authentication. Allow private players as e-auth service providers.
2. Inclusion: Enable multimodal and offline authentication.
3. Data security: License authorized service providers. Mandate access logs for regulator scrutiny.

### Face Authentication

Implementing face authentication on mobile apps creates non-linear scale in inclusive service delivery.

Key capabilities:
1. Mobile First: Deploy across OS platforms
2. Online/Offline: Local secure storage for offline delivery
3. Smart Synchronization: Offline data availability
4. Self/Assisted: Support both modes
5. Local Face Auth: Liveness checks on edge devices as reusable library
6. Device Registration: Manage granular controls
7. Assisted Operators: Trained for remote services

Risk mitigation: Test models for inclusion, integrate liveness detection, implement exception management, analyse telemetry data.

### eKYC / Identity Profile Sharing

eKYC extends authentication by enabling individuals to share profile fields with various systems. Upon authorization, ID authorities release minimum required demographic information and photographs via standard APIs.

Use cases: Bank account opening, mobile SIM KYC, securities accounts, government scheme enrollment.

### Single Sign-On (SSO)

SSO enables individuals to log in using a single identifier across multiple independent platforms. Supports OTP, biometric, and wallet-based authentication.

Benefits: Simplified access, revenue generation through digital engagement, consented profile sharing.

### QR Code for Offline ID

QR codes bridge physical and digital environments for payments, enrollment, credential verification, and tracking.

Design considerations:
1. Payload Compaction: ~2000 characters for mid-range smartphones
2. Digital Verification: Authenticate ID credentials
3. Biometric Matching: One-to-one face comparison

Recommendations: Versioning, multiple cryptographic signing options, key rotation, encryption for sensitive data, face recognition compatibility with 3+ algorithms.

Testing phases: Lab → Controlled Team → Field Integration → Regional Rollout → Formal Release.

---

## Technical Notes — Electronic Signature, PKI and Trust Infra

Three core elements:
1. Digital Signatures/PKI: Verifiable digital signatures ensuring documents and data remain unaltered
2. eSignatures: Electronic document signing via mobile
3. Granular Consent: User-controlled consent for data sharing

### Digital Signatures and PKI

PKI employs key pairs — private key (confidential) and public key (publicly available). Signing creates a distinctive digital signature. Verification uses the public key to validate. Extends to websites, servers, and software applications via digital certificates.

### eSign

eSignatures built on identity systems allow remote document signing. An eSign ecosystem enables legally valid signatures as a service, building on existing authentication and eKYC APIs.

### eConsent

Electronic consent is a machine-readable document specifying data share parameters. Three core sections:
1. Identifier Section: Data provider, consumer, individual, intermediaries
2. Data Section: Types, access, fields, date ranges, duration, frequency, purpose
3. Signatures: From framework-defined entities

Should allow condition-based consent approval with required checks.

---

## Technical Notes — Digital Payment Networks

Payments are the lifeblood of an economy. DPI approaches generate inclusion, innovation, and unprecedented scale through multiple device types.

Five key interventions:
1. Interoperable QR Code (P2P/P2M Payments)
2. Interoperable Authentication (P2P/P2M Payments)
3. Financial Address Mapper (G2P)
4. Cash in Cash Out (CiCO)
5. Interoperable Bill Payments Protocol

All transaction types can be powered by the same protocol.

### Financial Address

A financial address represents "where your money stays" using the format id-type:id@provider. Examples:
- token:12345@national-id
- mobile:12345@mobile-pymt
- account:12345@national-bank
- voucher:12345@food.coupon-network

Advantages: Protects privacy, enhances cybersecurity, supports multiple stores of value, builds trust.

Attribution: Derived from NPCI's UPI Protocol Virtual Address.

### Interoperable QR Code

A unified mechanism enabling payments through interoperable QR codes. Static QR (manual amount entry) and Dynamic QR (pre-entered amounts via POS).

Benefits: Seamless P2P/P2M/P2G transactions, merchant reconciliation, financial inclusion, fraud reduction.

Specification v0.8.2 (Draft). Supports: Scan & Pay, Click & Pay, Deep Linking, subscriptions, bill payments, refunds, BNPL.

Payment flow: Merchant registers → requests QR → customer scans → app verifies integrity → selects account → authorizes → payment processes → notifications sent.

### Interoperable Authentication

Central banks establish standardized transaction validation ensuring funds remain within banking infrastructure. Fintechs maintain UI while payment switch handles authentication and banks settle.

Three layers: User (fintechs), Authentication (payment switch), Settlement (banks).

### Interoperable Bill Payments

Enables viewing and paying all bills through a single platform of choice. Back-end remains decentralized while UX appears unified. APIs from billing authorities allow user-facing apps to retrieve data with consent.

Financial model: Minimal percentage per bill fetch, absorbed by issuers.

### Cash In Cash Out (CICO)

Trained agents as mobile banking agents/"micro-ATMs" travel to remote areas. Users provide bank account, national ID, and biometric authentication. Services: deposit, withdraw, transfer, bill pay, balance check, mini-statement — all at no cost.

### G2P Payments

Four key building blocks:
1. Unique ID/eKYC Layer
2. Financial Address Mapper
3. Last Mile Agents
4. Cross-Functional Registry Network

G2P DPI architecture ensures interoperability, inclusion, privacy, security, autonomy, and asynchronous adoption by design.

---

## Technical Notes — Data & Credentials

Data operates as digital capital. A DPI approach includes:
1. Verifiable credentials for certificates and claims
2. Personal data sharing in real-time with consent
3. Open anonymised datasets for research
4. Open AI/ML models (translation, underwriting, etc.)

### Verifiable Credentials

Issuing authorities make certificates tamper-proof while maintaining autonomy. Paper certificates can contain digitally signed QR codes. No centralization needed — departments retain control.

Three data-sharing modes:
1. Simultaneous consent and sharing through same platform (e.g., DigiLocker)
2. Separate consent and data management through different entities (e.g., Account Aggregator)
3. Data provider-managed consent

DPI approach layers:
- Technical: Open spec APIs, machine-readable signed QR codes, digitally signed documents, eLockers/Wallets
- Governance: Consent artifacts, Self-Regulatory Organizations
- Market: Multiple applications serving different populations

### Personal Data Sharing Primer

Three types of consented data sharing:
1. Verifiable credentials using e-wallets
2. System-to-system data sharing (high-trust environments)
3. Consent-led data sharing in a network (user wholly in control)

Cross-border data sharing: Credentials are most straightforward (no bilateral agreements needed). System-to-system requires more coordination. Federated anonymised data sets can be used for cross-border research.

### Data Standards

Guidelines dictating how data should be documented and recorded. Ensure syntax (structure) and semantics (meaning) are uniform. Examples: ISO 10962, ICD 10, LOINC, Account Aggregator standards. Many are extendable for country contextualization. Multiple standards can co-exist as long as they are self-identifying.

### eLockers

Online, verifiable digital locker applications. Services: anytime/anywhere access, authentication, granular consent-based data exchange.

Principles: Decentralised control, high-trust/low-risk, paperless power sharing, many apps/many certificates via open APIs.

Benefits: Stimulate digital economy, build inclusive systems, reduce corruption, enable convenient credential issuance, allow organic digital growth.

India's MSME portal Udyam integrated e-locker credential issuance in just three weeks.

### Non-Personal Anonymised Datasets

Collections preserving analytical value while maintaining anonymity. Purpose: innovation, transparency, scientific research, ML model training.

Design principles:
1. Federation by design (multiple datasets and providers)
2. Privacy by design
3. Open Access
4. Open Standards

A decentralized non-personal data network using protocols like Beckn enables: discovery of datasets, licensing/contracting, download/access, pricing, and update cycles.

### Building Data Analytics Pipelines

The Data Value Chain involves eight techniques: Ingestion, Cleansing, Transformation, Analysis, Storage, Querying, Visualization, Sharing.

Six key considerations: Data hosting, exchange methodologies, representation, processing/ETL, analytics, visualization platforms.

Open-source tools like Obsrv by Sunbird can manage up to 2 billion events per day.

---

## Technical Notes — Discovery & Fulfilment Networks

A DPI approach to discovery and fulfilment enables accessing any service or purchasing any good across multiple apps interoperably. This includes:
- Open APIs for government services
- Shared protocol for purchasing across sectors (BeckN), covering mobility, eCommerce, financial services

### Platforms to Protocols

Current platform model concentrates data among few companies, creating closed marketplaces. Problems: data fragmentation, monopolistic conduct, insufficient scalability, population exclusion.

Solution: Transition from centralized platforms to decentralized networks enabling secure, economical, and scalable transactions through open network infrastructure.

Reference: Beckn Protocol (becknprotocol.io)

---

## Initiatives — DPI Advisory

CDPI operates with five neutralities:
1. Software neutral (no product offering)
2. Technology neutral (open source or private)
3. Financing neutral (pro bono, philanthropically funded)
4. Government neutral (works with any interested government)
5. Country neutral (global team across 5 countries, 3 continents)

Three engagement levels:
- Conversational: Informal virtual guidance
- Co-Creation: Detailed strategy collaboration
- Roll-out Action: Sustained implementation support

Contact: info@cdpi.dev

---

## Initiatives — DPI as a Packaged Solution (DaaS)

DaaS enables rapid deployment of DPI, primarily through upgrades of existing infrastructure.

### Why DaaS?
Challenges: tension between urgency and speed, capacity constraints, financial limitations, procurement complexity.
DaaS addresses these while maintaining flexibility and extensibility.

### DaaS in a Nutshell

Three operational modules:
1. Open Source + Funded Service Provider (full DaaS package)
2. Open Source Artifacts Only (independent upgrade)
3. Pre-trained Service Provider Only (private vendor deployment)

Key characteristics: Fast-track deployment, works within existing procurement, achieves population-scale from inception.

### Reusable DaaS Artefacts

Five key artefacts:
1. Execution Readiness Checklists
2. Legal Arrangement Templates
3. Sample Costing Models
4. Policy Kits
5. Program Rollout Guidelines

### 3-Step Process from Idea to Implementation

1. Choose use case from available products
2. Converse with CDPI, DPGs, and ecosystem players
3. Configure to local systems with pre-trained service providers

Benefits: Faster rollout, lower cost, government IP ownership, reduced capacity requirements, outcome-based costing, choice of providers and clouds.

### Cohort 1 Offerings
1. Digital credentials (verifiable certificates with signed QR codes)
2. Digital authentication (ID verification)
3. ID Account Mapper (beneficiary ID to bank account mapping)

### Upcoming Cohorts
Civil and Functional Registries and AI Assistant with open APIs.

### FAQs
- Countries retain full control and IP ownership
- Cloud is NOT compulsory (on-premises works)
- Traditional 24-month rollout compressed to 8-12 weeks
- Package installation under 8 hours, integration 1-3 weeks
- Minimal vendor lock-in (fully open source)
- Offline functionality supported
- Contact: info@cdpi.dev

### Co-Create with Us
Open invitation to DPGs, funders, service providers, and technical advisory providers. 7-8 implementation-ready countries in pipeline across Latin America, Africa, and Asia.

---

## Initiatives — Funded DaaS Program

Competitive application for nations to demonstrate capacity for quick DPI implementation. Selected nations receive DaaS packages and supplementary funding. Implementation spans 180 days (90-day initial phase + 90-day proof of concept).

Available products: Digital authentication, Digital Credentials, ID-Account mapper.

Support: DaaS package, certified implementation partners, cloud providers, Technology Service Providers, philanthropic funding.

Contact: info@cdpi.dev

---

## Initiatives — DPI Residents Program

Program details forthcoming.

---

## Curated Global Specifications

### Identifiers & Registries — Auth & eKYC
- OAuth: https://www.rfc-editor.org/rfc/rfc6749
- OpenID: https://openid.net/developers/
- SAML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

### Signatures & Consent — eSign
- PKCS #10: https://datatracker.ietf.org/doc/html/rfc2986

### Signatures & Consent — Digital Data Sharing Consents
- Electronic Consent artefact (India): https://dla.gov.in/sites/default/files/pdf/MeitY-Consent-Tech-Framework%20v1.1.pdf
- Consent building block (Govstack): https://govstack.gitbook.io/bb-consent/

### Payments — G2P, P2P & P2M
- G2P Connect: https://g2pconnect.cdpi.dev/g2p-connect/readme | https://g2p-connect.github.io/specs/
- UK Open Banking Payments: https://standards.openbanking.org.uk/api-specifications/
- ISO 20022: https://www.iso20022.org/iso-20022-message-definitions?business-domain=1

### Payments — Reference Implementations
- Mojaloop: https://docs.mojaloop.io/getting-started/
- Mifos: https://mifos.org/resources/documentation/
- OpenG2P: https://docs.openg2p.org/guides/developer-guides
- OpenSPP: https://docs.openspp.org/index.html
- DIGIT: https://core.digit.org/

### Data — Verifiable Credentials Issuance
- W3C VC Data Model: https://www.w3.org/TR/vc-data-model/
- W3C VC Implementation Guide: https://www.w3.org/TR/vc-imp-guide/
- W3C VC API: https://w3c-ccg.github.io/vc-api/
- G2P Connect Credentialing: https://g2pconnect.cdpi.dev/protocol/interfaces/credentialing

### Data — Reference Implementations (Issuance)
- Sunbird VC: https://docs.sunbirdrc.dev/learn/readme
- Inji by MOSIP: https://docs.mosip.io/inji/
- CREDEBL: https://docs.credebl.id/en/intro/what-is-credebl/

### Data — Verifiable Credentials Presentation
- W3C Implementation Guide: https://www.w3.org/TR/vc-imp-guide/

### Data — Consented Data Sharing
- X-Road: https://docs.x-road.global/
- Account Aggregator: https://github.com/Sahamati/account-aggregator-standards

### Data — ML Datasets
- Bhashini (local languages): https://bhashini.gov.in/ulca/model/benchmark-datasets

### Discovery & Fulfilment — eCommerce
- Beckn Protocol: https://becknprotocol.io/ | https://github.com/beckn/protocol-specifications

### Discovery & Fulfilment — Education
- Sunbird: https://sunbird.org/product/building-blocks
- BeckN DSEP: https://github.com/beckn/DSEP-Specification

### Discovery & Fulfilment — Healthcare
- BeckN DHP: https://developers.becknprotocol.io/docs/introduction/introduction/
- Health Claims Exchange (HCX): https://docs.hcxprotocol.io
- DEPA: https://depa.world
- HL7 FHIR: http://www.hl7.org/fhir/documentation.html

### Discovery & Fulfilment — Health Information Systems
- OpenMRS: https://wiki.openmrs.org/
- DHIS2: https://dhis2.org/about/
- OpenEHR: https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html
- OpenELIS: http://docs.openelis-global.org/en/latest/

### Discovery & Fulfilment — Vaccination Certificate
- DIVOC: https://divoc.digit.org/

### Discovery & Fulfilment — Social Networks
- DSNP: https://dsnp.org/introducing-dsnp.html | https://spec.dsnp.org/