Che cos’è la Digital Public Infrastructure

La Digital Public Infrastructure (DPI) rappresenta un cambio di paradigma nella progettazione dei servizi digitali governativi. Invece di costruire soluzioni monolitiche per ogni singolo servizio pubblico, l’approccio DPI prevede la creazione di building block condivisi, modulari e interoperabili che qualsiasi servizio - pubblico o privato - può riutilizzare. L’analogia più efficace è quella con le infrastrutture fisiche: così come strade, reti elettriche e acquedotti sono piattaforme condivise su cui si costruiscono servizi diversi, la DPI fornisce i “binari digitali” su cui corrono identità verificate, pagamenti istantanei e scambi di dati sicuri.

Nel 2025, almeno 64 paesi dispongono di sistemi di identità digitale di tipo DPI, 97 paesi hanno sistemi di pagamento digitale interoperabili e 103 paesi hanno framework di scambio dati strutturati. La DPI non è più un concetto teorico: è un’infrastruttura operativa che tocca miliardi di persone.

Perché la DPI è Diversa dall’e-Government Tradizionale

L’e-Government tradizionale ha prodotto silos: ogni ministero costruisce il proprio sistema, con la propria base dati utenti, il proprio meccanismo di autenticazione, il proprio gateway di pagamento. Il risultato è duplicazione, incompatibilità e costi esponenziali. La DPI ribalta questa logica: costruisci una volta i blocchi fondamentali, e tutto l’ecosistema li riutilizza.

I Tre Pilastri Fondamentali della DPI

Ogni implementazione DPI si fonda su tre pilastri interconnessi che, combinati, creano un ecosistema digitale completo. Questi pilastri non sono indipendenti: la loro potenza emerge dalla sinergia.

1. Identità Digitale (Digital Identity)

Il primo pilastro è la capacità di verificare in modo univoco l’identità di ogni cittadino, azienda o dispositivo nell’ecosistema. Senza un sistema di identità digitale robusto, nessun altro servizio può funzionare in modo sicuro. L’identità digitale DPI deve essere: universale (coprire l’intera popolazione), verificabile (con prove crittografiche), minimale (condividere solo i dati necessari) e interoperabile (funzionare attraverso enti e servizi diversi).

2. Pagamenti Digitali (Digital Payments)

Il secondo pilastro abilita lo scambio di valore economico in tempo reale tra qualsiasi coppia di attori nell’ecosistema. Un rail di pagamento DPI non è semplicemente un gateway: è un’infrastruttura aperta che permette a qualsiasi banca, fintech o istituzione di inviare e ricevere pagamenti istantanei attraverso API standardizzate. Il modello di riferimento è UPI in India, che nel gennaio 2026 ha processato 21,7 miliardi di transazioni per un valore superiore a 28.330 miliardi di rupie.

3. Scambio Dati (Data Exchange)

Il terzo pilastro fornisce un layer sicuro e standardizzato per lo scambio di informazioni tra sistemi diversi, nel rispetto del consenso dell’utente e delle normative sulla privacy. Un framework di data exchange DPI garantisce che i dati fluiscano dove servono, quando servono, con tracciabilità completa e cifratura end-to-end.

India Stack: Il Modello di Riferimento Globale

L’India Stack è il caso più maturo e studiato di DPI al mondo. Lanciato progressivamente dal 2009, rappresenta un ecosistema di infrastrutture digitali che serve oltre 1,4 miliardi di persone. Il suo successo ha ispirato il G20, le Nazioni Unite e decine di paesi a replicare il modello. Nel 2025, l’India ha esportato la tecnologia UPI in oltre 25 paesi.

Aadhaar: Identità Biometrica su Scala Nazionale

Aadhaar è il sistema di identità digitale più grande del mondo, con oltre 1,3 miliardi di iscrizioni. Ogni residente riceve un numero univoco a 12 cifre legato ai propri dati biometrici (impronte digitali e scansione dell’iride). L’architettura di Aadhaar si basa su principi di security-by-design: i protocolli biometrici sono stati integrati nell’infrastruttura fin dalla concezione, non aggiunti successivamente.

L’API di verifica Aadhaar espone un endpoint di autenticazione che supporta tre modalità:

# Aadhaar Authentication API - Flusso di Verifica

# 1. Demographic Authentication
POST /api/v2/auth/demographic
Content-Type: application/xml
{
  "aadhaar_number": "XXXX-XXXX-XXXX",
  "name": "...",
  "dob": "YYYY-MM-DD",
  "gender": "M|F|T",
  "address": {
    "house": "...",
    "street": "...",
    "pincode": "XXXXXX"
  }
}

# 2. Biometric Authentication (Fingerprint/Iris)
POST /api/v2/auth/biometric
{
  "aadhaar_number": "XXXX-XXXX-XXXX",
  "biometric_data": {
    "type": "FIR|IIR",   # Fingerprint / Iris
    "position": "LEFT_INDEX",
    "data": "<base64_encoded_biometric>"
  },
  "device_info": {
    "device_id": "...",
    "rdsv": "...",        # Registered Device Service version
    "mi": "...",          # Model Info
    "mc": "..."           # Machine Code (signed)
  }
}

# 3. OTP-based Authentication
POST /api/v2/auth/otp/generate
{ "aadhaar_number": "XXXX-XXXX-XXXX" }

POST /api/v2/auth/otp/verify
{
  "aadhaar_number": "XXXX-XXXX-XXXX",
  "otp": "XXXXXX",
  "txn_id": "..."
}

# Response (comune a tutti i metodi)
{
  "status": "Y|N",
  "auth_token": "...",
  "txn_id": "...",
  "err_code": null,
  "info": {
    "auth_type": "DEMO|BIO|OTP",
    "timestamp": "2026-03-09T10:30:00Z"
  }
}

UPI: Pagamenti Istantanei Interoperabili

Il Unified Payments Interface (UPI) è il rail di pagamento in tempo reale sviluppato dalla NPCI (National Payments Corporation of India). L’architettura UPI si basa su un central switch che interconnette tutte le banche e i Payment Service Provider (PSP) del paese, abilitando trasferimenti bank-to-bank istantanei, 24/7, a costo zero.

L’architettura a strati di UPI comprende:

• App Layer: le applicazioni utente (Google Pay, PhonePe, Paytm, BHIM)
• PSP Layer: i Payment Service Provider che gestiscono le transazioni per conto delle banche
• NPCI Switch: il cuore dell’infrastruttura che instrada le transazioni tra banche diverse
• Bank Systems: i core banking delle banche partecipanti
• Authentication Layer: device binding, PIN cifrato e verifica multi-fattore
• Settlement Layer: regolamento interbancario in cicli multipli giornalieri

# Architettura UPI - Flusso di una Transazione

# 1. L'utente inizia il pagamento dall'app
# 2. La richiesta arriva al PSP (Payment Service Provider)
# 3. Il PSP inoltra al NPCI Central Switch
# 4. Il switch identifica la banca destinataria
# 5. La banca destinataria conferma la disponibilità fondi
# 6. Il switch completa la transazione e notifica entrambe le parti

# Flusso tecnico semplificato:

[Payer App] --> [Payer PSP] --> [NPCI UPI Switch] --> [Payee PSP] --> [Payee Bank]
     ^                              |                                      |
     |                              v                                      v
     |                     [Transaction Log]                    [Credit Account]
     |                              |
     +--------- [Response: Success/Failure] <--------+

# API di Collect Request (esempio semplificato)
POST /upi/v2/collect
{
  "payer_vpa": "user@bankpsp",
  "payee_vpa": "merchant@bankpsp",
  "amount": {
    "value": "500.00",
    "currency": "INR"
  },
  "txn_note": "Payment for order #12345",
  "txn_id": "TXN202603091030ABC",
  "device_fingerprint": "...",
  "encrypted_pin": "<encrypted_upi_pin>"
}

# Response
{
  "status": "SUCCESS",
  "txn_id": "TXN202603091030ABC",
  "rrn": "631012345678",   # Retrieval Reference Number
  "approval_number": "ABC123",
  "timestamp": "2026-03-09T10:30:05Z",
  "payer_vpa": "user@bankpsp",
  "payee_vpa": "merchant@bankpsp",
  "amount": "500.00"
}

DigiLocker e ONDC: Data Exchange e Commerce Aperto

DigiLocker è la piattaforma di document exchange che permette ai cittadini indiani di archiviare e condividere documenti ufficiali (patente, certificati scolastici, tessera sanitaria) in formato digitale verificabile. L’architettura è basata su un modello di consent-based sharing: il documento non viene mai copiato, ma viene fornito un link verificabile all’originale, con validità temporale controllata dal titolare.

L’Open Network for Digital Commerce (ONDC) estende il paradigma DPI all’e-commerce, creando un protocollo aperto che separa le piattaforme di ricerca/discovery dai venditori e dai servizi logistici, eliminando il monopolio delle grandi piattaforme chiuse.

L’Approccio Europeo: eIDAS 2.0 e EUDI Wallet

L’Europa sta costruendo la propria DPI con un approccio diverso dall’India: dove India Stack è nato da un’esigenza di inclusione finanziaria in un paese con infrastrutture limitate, l’approccio europeo parte dalla protezione dei diritti fondamentali, dalla privacy-by-design e dalla sovranità digitale. Il Regolamento eIDAS 2.0 (Regolamento UE 2024/1183) è il pilastro legislativo che rende obbligatorio per ogni Stato membro fornire un wallet di identità digitale ai propri cittadini entro dicembre 2026.

EUDI Wallet: Architettura e Principi

L’EU Digital Identity Wallet (EUDI) è progettato secondo principi fondamentalmente diversi dai sistemi centralizzati:

• Storage locale: i dati risiedono sul dispositivo dell’utente, non su server centrali
• Controllo dell’utente: l’utente decide quali informazioni condividere con chi
• Zero tracking: il design prevede che nessun attore possa profilare l’utente
• Privacy dashboard: trasparenza completa su come e con chi vengono condivise le informazioni
• Gratuito: emissione, uso e revoca gratuiti per tutte le persone fisiche

# EUDI Wallet - Architettura Semplificata

# Componenti principali:

[Citizen Device]
    |
    +-- [EUDI Wallet App]
    |       |
    |       +-- [Credential Store]     # PID, attestazioni, certificati
    |       +-- [Crypto Engine]        # Chiavi private, firma digitale
    |       +-- [Privacy Dashboard]    # Log condivisioni, revoche
    |       +-- [Consent Manager]      # Gestione consensi granulari
    |
    +-- [Secure Element / TEE]         # Hardware-backed key storage

# Flusso di Verifiable Presentation
# 1. Il Relying Party richiede attributi specifici
# 2. Il Wallet mostra all'utente cosa viene richiesto
# 3. L'utente approva/nega selettivamente
# 4. Il Wallet crea una Verifiable Presentation firmata
# 5. Il Relying Party verifica la firma e la validita

# Esempio: Verifica eta senza rivelare la data di nascita
POST /wallet/v1/presentation
{
  "verifier_id": "bar-nightclub-001",
  "requested_claims": ["age_over_18"],
  "purpose": "Age verification for entry",
  "nonce": "abc123xyz",
  "response_uri": "https://verifier.example.com/callback"
}

# Wallet Response (selective disclosure)
{
  "vp_token": "<signed_verifiable_presentation>",
  "presentation_submission": {
    "descriptor_map": [
      {
        "id": "age_over_18",
        "format": "mso_mdoc",
        "path": "$.credentials[0]"
      }
    ]
  },
  "disclosed_claims": {
    "age_over_18": true
    # NOTA: la data di nascita NON viene condivisa
  }
}

Timeline di Implementazione eIDAS 2.0

EBSI: European Blockchain Services Infrastructure

L’EBSI aggiunge un ulteriore layer all’architettura DPI europea: una blockchain permissioned che fornisce servizi di verifiable credentials, notarizzazione, tracciabilità e timestamping condivisi tra tutti gli Stati membri. L’EBSI non è un sostituto dei sistemi tradizionali, ma un complemento che aggiunge garanzie di immutabilità e verificabilità crittografica ai processi transfrontalieri.

GovStack: Lo Standard dei Building Block

GovStack è un’iniziativa internazionale guidata da ITU, GIZ, Estonia e DIAL che definisce specifiche tecniche aperte per i building block dei servizi digitali governativi. Con la strategia GovSpecs 2.0 (2025-2027), GovStack ha consolidato un framework che oltre 20 paesi stanno già adottando per progettare le proprie architetture DPI. Dal 2026, le specifiche integrano anche funzionalità di AI-readiness.

I Nove Building Block Fondamentali

GovStack definisce nove building block che costituiscono la base di qualsiasi servizio digitale governativo. Ogni building block è indipendentemente deployabile, espone API RESTful standardizzate e comunica con gli altri attraverso protocolli ben definiti.

# GovStack Building Block - Esempio di Architettura Completa
# Caso d'uso: Richiesta sussidio sociale

# 1. REGISTRATION BB - Il cittadino si registra alla piattaforma
POST /api/v1/registration/applications
{
  "program_id": "social-subsidy-2026",
  "applicant": {
    "identity_ref": "ID-2026-XXXX",
    "contact": {
      "email": "citizen@email.com",
      "phone": "+39XXXXXXXXXX"
    }
  }
}
# Response: { "application_id": "APP-001", "status": "SUBMITTED" }

# 2. IDENTITY BB - Verifica identità del richiedente
POST /api/v1/identity/verify
{
  "identity_ref": "ID-2026-XXXX",
  "verification_type": "STRONG",
  "purpose": "social-subsidy-eligibility",
  "required_loa": "HIGH"    # Level of Assurance
}
# Response: { "verified": true, "loa": "HIGH", "method": "eID+biometric" }

# 3. CONSENT BB - Richiesta consenso per accesso dati fiscali
POST /api/v1/consent/requests
{
  "subject_id": "ID-2026-XXXX",
  "requester": "ministry-of-welfare",
  "data_sources": [
    {
      "provider": "tax-authority",
      "data_type": "annual_income",
      "period": "2025"
    },
    {
      "provider": "social-security",
      "data_type": "employment_status",
      "period": "current"
    }
  ],
  "purpose": "Verifica requisiti sussidio sociale",
  "retention_period": "90d",
  "expires_at": "2026-04-09T00:00:00Z"
}
# Response: { "consent_id": "CON-001", "status": "PENDING_APPROVAL" }

# 4. INFORMATION MEDIATOR BB - Recupero dati (post-consenso)
POST /api/v1/mediator/query
{
  "consent_id": "CON-001",
  "queries": [
    {
      "source": "tax-authority",
      "endpoint": "/citizen/income",
      "params": { "year": 2025, "citizen_id": "ID-2026-XXXX" }
    },
    {
      "source": "social-security",
      "endpoint": "/citizen/employment",
      "params": { "citizen_id": "ID-2026-XXXX" }
    }
  ]
}
# Response: aggregated data from multiple sources

# 5. WORKFLOW BB - Orchestrazione decisione
POST /api/v1/workflow/execute
{
  "workflow_id": "subsidy-evaluation",
  "application_id": "APP-001",
  "input_data": {
    "identity_verified": true,
    "income_2025": 18500.00,
    "employment_status": "unemployed",
    "household_size": 3
  }
}
# Response: { "decision": "APPROVED", "amount": 600.00, "frequency": "monthly" }

# 6. PAYMENTS BB - Erogazione sussidio
POST /api/v1/payments/disbursements
{
  "beneficiary_id": "ID-2026-XXXX",
  "amount": 600.00,
  "currency": "EUR",
  "payment_method": "bank_transfer",
  "reference": "APP-001",
  "schedule": {
    "type": "RECURRING",
    "frequency": "MONTHLY",
    "start_date": "2026-04-01"
  }
}
# Response: { "payment_id": "PAY-001", "status": "SCHEDULED" }

# 7. MESSAGING BB - Notifica al cittadino
POST /api/v1/messaging/send
{
  "recipient_id": "ID-2026-XXXX",
  "template": "subsidy-approved",
  "channels": ["sms", "email", "push"],
  "parameters": {
    "amount": "600.00 EUR",
    "start_date": "1 Aprile 2026",
    "reference": "APP-001"
  }
}
# Response: { "message_id": "MSG-001", "delivered": ["sms", "email"] }

Framework di Interoperabilità: X-Road e DIGIT

X-Road: Il Backbone Digitale dell’Estonia

X-Road è il framework di interoperabilità sviluppato dall’Estonia nel 2001 e oggi adottato da oltre 25 paesi. È il componente che rende possibile lo scambio sicuro di dati tra qualsiasi sistema informativo connesso alla rete governativa, ed è rilasciato come open source sotto licenza MIT dal 2016.

L’architettura X-Road si basa su tre componenti chiave:

• Central Server: mantiene il registro dei membri, le policy di sicurezza e la configurazione globale della rete
• Security Server: installato presso ogni organizzazione partecipante, gestisce autenticazione, autorizzazione, cifratura e logging di ogni transazione
• Service Provider/Consumer: i sistemi informativi che producono o consumano servizi tramite X-Road

Le identità di ogni organizzazione e Security Server sono verificate tramite certificati X.509 emessi da una Certification Authority trusted. Ogni messaggio è firmato digitalmente, cifrato in transito e loggato in modo immutabile su entrambi i lati della comunicazione.

# X-Road - Architettura di Interoperabilità

#   Organizzazione A             Central Server            Organizzazione B
#   +----------------+      +-------------------+      +----------------+
#   |  Information    |      | - Member Registry |      |  Information   |
#   |  System A       |      | - Security Policy |      |  System B      |
#   |  (Consumer)     |      | - Config Sync     |      |  (Provider)    |
#   +-------+--------+      +-------------------+      +-------+--------+
#           |                                                   |
#   +-------+--------+                                 +-------+--------+
#   | Security Server|  <--- TLS + Signed SOAP --->   | Security Server|
#   | - Auth         |                                 | - Auth         |
#   | - Encryption   |                                 | - Encryption   |
#   | - Logging      |                                 | - Logging      |
#   | - Timestamping |                                 | - Timestamping |
#   +----------------+                                 +----------------+

# Requisiti soddisfatti da X-Road:
# 1. Interoperabilità: funziona tra sistemi eterogenei con API language-agnostic
# 2. Integrita dei dati: nessuna informazione alterata durante il trasferimento
# 3. Privacy: tutti i dati cifrati, protetti da accessi non autorizzati
# 4. Non-repudiabilita: ogni transazione firmata e loggata su entrambi i lati

# Esempio di richiesta X-Road (SOAP/REST)
# Service: popolazione.anagrafe/getCitizenData/v3
{
  "client": {
    "xRoadInstance": "EE",
    "memberClass": "GOV",
    "memberCode": "70000001",
    "subsystemCode": "welfare-system"
  },
  "service": {
    "xRoadInstance": "EE",
    "memberClass": "GOV",
    "memberCode": "70000002",
    "subsystemCode": "population-registry",
    "serviceCode": "getCitizenData",
    "serviceVersion": "v3"
  },
  "id": "REQ-2026-03-09-001",
  "protocolVersion": "4.0"
}

DIGIT India: Data Empowerment and Protection Architecture

Sul fronte indiano, il framework DIGIT (Digital Infrastructure for Governance, Impact and Transformation) fornisce una piattaforma open source per la digitalizzazione dei servizi pubblici urbani e rurali. A differenza di X-Road, che è un layer di interoperabilità puro, DIGIT è un ecosistema più ampio che include microservizi pre-costruiti, dashboard analitiche e strumenti di citizen engagement.

Complementare a DIGIT, la DEPA (Data Empowerment and Protection Architecture) definisce come i dati dei cittadini possono essere condivisi in modo sicuro attraverso Account Aggregator, entità fiduciarie regolamentate dalla Reserve Bank of India che mediano il flusso di dati finanziari con il consenso esplicito dell’utente.

API Design per Servizi Governativi

La progettazione delle API è il cuore tecnico della DPI. Le API governative devono soddisfare requisiti che vanno ben oltre quelli delle API commerciali: disponibilità 99,99%, retrocompatibilità garantita per anni, audit trail completo, supporto multi-lingua e conformità a standard nazionali e internazionali.

Pattern di Design per API Governative

# API Gateway per Servizi Governativi - Pattern di Riferimento

# Struttura URL standardizzata:
# /{country}/gov/api/{version}/{domain}/{resource}

# Esempi:
# GET  /it/gov/api/v2/citizens/CF-XXXXXX/profile
# POST /it/gov/api/v2/welfare/applications
# GET  /it/gov/api/v2/tax/declarations?year=2025

# Standard Headers (obbligatori per tutte le API governative):
#
# X-Request-ID:        UUID univoco per tracciabilita
# X-Correlation-ID:    ID per correlare richieste cross-service
# X-Gov-Client-ID:     Identificativo del sistema chiamante
# X-Gov-Consent-Token: Token di consenso dell'utente (dove richiesto)
# X-Gov-Audit-Actor:   Identificativo dell'operatore (per audit)
# Accept-Language:     Lingua della risposta (it, en, de, fr, ...)

# Versionamento: URI-based per major version, header per minor
# GET /it/gov/api/v2/citizens/...
# X-Api-Version: 2.3.1

# Rate Limiting differenziato per tipo di consumer:
# - Sistemi interni PA:      10.000 req/min
# - Enti accreditati:         1.000 req/min
# - Applicazioni cittadini:     100 req/min
# - Sviluppatori (sandbox):     50 req/min

# Envelope di risposta standard:
{
  "meta": {
    "request_id": "550e8400-e29b-41d4-a716-446655440000",
    "timestamp": "2026-03-09T10:30:00Z",
    "api_version": "2.3.1",
    "locale": "it-IT"
  },
  "data": {
    # ... payload della risposta
  },
  "pagination": {
    "total": 150,
    "page": 1,
    "per_page": 20,
    "next_cursor": "eyJpZCI6MTIzfQ=="
  },
  "errors": null,
  "warnings": [
    {
      "code": "DEPRECATED_FIELD",
      "message": "Il campo 'codice_fiscale_old' sarà rimosso nella v3",
      "target": "data.codice_fiscale_old"
    }
  ]
}

# Error Response standard (RFC 7807 - Problem Details):
{
  "type": "https://gov.it/errors/consent-required",
  "title": "Consenso richiesto",
  "status": 403,
  "detail": "L'accesso ai dati fiscali richiede il consenso esplicito del cittadino",
  "instance": "/it/gov/api/v2/tax/declarations?year=2025",
  "extensions": {
    "consent_url": "https://consent.gov.it/request/CON-001",
    "required_scopes": ["tax:read:annual_income"],
    "expires_in": 3600
  }
}

Consent Management: Il Cuore della Privacy nella DPI

Il Consent Building Block è forse il componente più critico in una DPI moderna, specialmente in contesti come quello europeo dove il GDPR impone requisiti stringenti. Il consent management non è un semplice “accetto/rifiuto”: è un sistema complesso che deve gestire consensi granulari, revocabili, con scadenza temporale e audit trail completo.

# Consent Management Service - Implementazione di Riferimento

# Modello dati del consenso
{
  "consent_id": "CON-2026-03-001",
  "version": 1,
  "status": "ACTIVE",             # PENDING | ACTIVE | REVOKED | EXPIRED
  "subject": {
    "id": "CITIZEN-ID-XXX",
    "type": "NATURAL_PERSON"
  },
  "controller": {
    "id": "MINISTRY-WELFARE",
    "name": "Ministero del Lavoro e delle Politiche Sociali",
    "dpo_contact": "dpo@lavoro.gov.it"
  },
  "purpose": {
    "code": "SOCIAL_SUBSIDY_EVAL",
    "description": "Valutazione requisiti per sussidio sociale",
    "legal_basis": "GDPR Art. 6(1)(a) - Consenso esplicito"
  },
  "data_items": [
    {
      "source": "agenzia-entrate",
      "category": "FINANCIAL",
      "specific_data": ["annual_income", "tax_declarations"],
      "period": "2024-2025",
      "access_type": "READ_ONCE"    # READ_ONCE | READ_RECURRING | STREAM
    },
    {
      "source": "inps",
      "category": "EMPLOYMENT",
      "specific_data": ["employment_status", "contribution_history"],
      "period": "current",
      "access_type": "READ_RECURRING"
    }
  ],
  "constraints": {
    "retention_period": "90d",
    "geographic_restriction": "EU",
    "no_automated_decisions": true,
    "no_third_party_sharing": true
  },
  "lifecycle": {
    "created_at": "2026-03-09T10:00:00Z",
    "granted_at": "2026-03-09T10:05:23Z",
    "expires_at": "2026-06-09T10:05:23Z",
    "revoked_at": null,
    "last_accessed": "2026-03-09T10:30:00Z",
    "access_count": 1
  },
  "audit_trail": [
    {
      "action": "CREATED",
      "timestamp": "2026-03-09T10:00:00Z",
      "actor": "welfare-portal",
      "ip": "x.x.x.x"
    },
    {
      "action": "GRANTED",
      "timestamp": "2026-03-09T10:05:23Z",
      "actor": "citizen-wallet",
      "method": "EUDI_WALLET_CONFIRM"
    },
    {
      "action": "DATA_ACCESSED",
      "timestamp": "2026-03-09T10:30:00Z",
      "actor": "welfare-evaluation-service",
      "data_source": "agenzia-entrate"
    }
  ],
  "signature": "<digital_signature_of_consent_record>"
}

# API per gestione consenso:

# Creazione richiesta di consenso
POST   /api/v1/consent/requests

# Approvazione/rifiuto da parte del cittadino
PUT    /api/v1/consent/{consent_id}/grant
PUT    /api/v1/consent/{consent_id}/deny

# Revoca consenso (diritto garantito GDPR)
DELETE /api/v1/consent/{consent_id}

# Verifica stato consenso (per i data provider)
GET    /api/v1/consent/{consent_id}/verify
# Response: { "valid": true, "scopes": [...], "expires_in": 7776000 }

# Lista consensi attivi per un cittadino
GET    /api/v1/consent/subject/{subject_id}
# Response: lista paginata di tutti i consensi attivi/scaduti/revocati

# Audit trail completo
GET    /api/v1/consent/{consent_id}/audit

Security e Privacy by Design nella DPI

La sicurezza in un sistema DPI non può essere un’aggiunta successiva: deve essere integrata nel DNA dell’architettura fin dalla concezione. Come evidenziato dal World Economic Forum, i principi di security-by-design sono stati incorporati nei protocolli biometrici di Aadhaar, nei framework transazionali di UPI e nelle architetture di condivisione dati prima che un singolo utente fosse registrato.

Principi di Sicurezza DPI

Scalare la DPI: Dal Prototipo alla Scala Nazionale

Portare una DPI dalla fase prototipale alla scala di un’intera popolazione è una delle sfide ingegneristiche più complesse nel panorama tecnologico. I numeri parlano chiaro: UPI processa oltre 700 milioni di transazioni al giorno, Aadhaar gestisce centinaia di milioni di autenticazioni mensili, e X-Road in Estonia processa oltre 1 miliardo di query all’anno per un paese di 1,3 milioni di abitanti.

Pattern Architetturali per la Scalabilità

• Event-Driven Architecture: i building block comunicano tramite eventi asincroni, disaccoppiando produttori e consumatori e permettendo scaling indipendente
• CQRS (Command Query Responsibility Segregation): separazione tra operazioni di scrittura (transazioni, registrazioni) e lettura (query, report), con database ottimizzati per ciascuna
• Sharding geografico: partizionamento dei dati per regione/stato per ridurre latenza e rispettare requisiti di data residency
• Circuit Breaker: ogni integrazione tra building block protetta da circuit breaker per evitare cascading failures
• Blue-Green Deployment: aggiornamenti senza downtime, critici per servizi che non possono permettersi interruzioni
• Multi-Region Active-Active: replica attiva in più data center per disaster recovery con RPO prossimo a zero

Case Study: Tre Modelli DPI a Confronto

Estonia: e-Residency e il Governo Più Digitale del Mondo

L’Estonia è il caso più citato di digitalizzazione governativa completa. Con soli 1,3 milioni di abitanti, il 99% dei servizi pubblici è disponibile online (le uniche eccezioni sono matrimonio, divorzio e compravendita immobiliare, che richiedono ancora presenza fisica). Il programma e-Residency, lanciato nel 2014, permette a chiunque nel mondo di ottenere un’identità digitale estone e accedere ai servizi di business del paese.

Il cuore tecnico è X-Road, che dal 2001 interconnette tutti i sistemi informativi della pubblica amministrazione. Ogni ente mantiene i propri dati (principio “once only”: il dato viene registrato una sola volta e condiviso dove necessario), e X-Road garantisce lo scambio sicuro, firmato e loggato.

India: UPI e l’Inclusione Finanziaria su Scala Miliardaria

India Stack ha dimostrato che la DPI può funzionare a una scala senza precedenti. Il percorso è stato: Aadhaar (identità, dal 2009) → Jan Dhan Yojana (conti bancari per tutti, dal 2014) → UPI (pagamenti istantanei, dal 2016) → DigiLocker (documenti, dal 2015) → ONDC (commerce aperto, dal 2022). Questa sequenza - nota come JAM Trinity (Jan Dhan + Aadhaar + Mobile) - ha portato oltre 500 milioni di persone nell’economia digitale formale.

Singapore: SingPass e il Modello Smart Nation

SingPass (Singapore Personal Access) serve il 97% dei cittadini e residenti permanenti con età superiore ai 15 anni e gestisce circa 300 milioni di transazioni personali e aziendali ogni anno, connettendo oltre 2.700 servizi di 800+ enti pubblici e privati. L’architettura NDI (National Digital Identity) di Singapore si distingue per:

• MyInfo: profilo digitale pre-compilato con dati verificati dal governo, che elimina la necessità di ripetere l’inserimento dati
• Face Verification: autenticazione biometrica facciale per transazioni ad alto rischio
• Sign: firma digitale legalmente valida integrata nell’ecosistema
• Verify: verifica dell’identità in presenza tramite QR code, senza condividere documenti fisici

Implementare una DPI: Lezioni Apprese

Il Futuro della DPI: Tendenze 2026-2030

Il panorama DPI è in rapida evoluzione. Diverse tendenze stanno emergendo che ridefiniranno l’architettura delle infrastrutture digitali pubbliche nei prossimi anni:

• AI-Readiness nei Building Block: GovSpecs 2.0 prevede dal 2026 l’integrazione di funzionalità AI-ready nelle specifiche dei building block, abilitando servizi proattivi e predittivi
• Verifiable Credentials generalizzate: oltre l’identità, le credenziali verificabili si estenderanno a titoli di studio, licenze professionali, certificazioni sanitarie e qualifiche lavorative
• Cross-border DPI: l’interoperabilità tra DPI nazionali diventerà la norma, con EUDI Wallet e l’export di UPI come modelli di riferimento
• Decentralized Identity (SSI): i modelli di Self-Sovereign Identity, dove il cittadino controlla completamente i propri dati senza dipendere da un provider centrale, guadagneranno trazione
• Green DPI: l’efficienza energetica e la sostenibilità ambientale diventeranno requisiti di progettazione, con metriche di carbon footprint per transazione

Conclusione

La Digital Public Infrastructure non è un progetto tecnologico: è una scelta di architettura sociale. Decidere di costruire building block condivisi, aperti e interoperabili significa scegliere un modello dove l’innovazione è distribuita, dove qualsiasi attore - pubblico o privato - può costruire servizi sulle stesse fondamenta, e dove il costo marginale di un nuovo servizio digitale tende a zero.

I tre modelli che abbiamo analizzato - India Stack per la scala, Estonia per l’eleganza architetturale, Singapore per l’efficienza - dimostrano che non esiste un unico modo di implementare la DPI, ma esistono principi universali: modularità, interoperabilità, privacy-by-design, standard aperti e design for failure. Con GovStack che sta standardizzando i building block, eIDAS 2.0 che porterà il wallet digitale a 450 milioni di europei, e l’India che esporta UPI in 25+ paesi, siamo all’inizio di un’era in cui la DPI diventerà infrastruttura tanto fondamentale quanto l’elettricità o Internet.

Per gli sviluppatori e gli architetti software, comprendere i pattern DPI non è solo una competenza tecnica: è la chiave per partecipare alla costruzione dell’infrastruttura digitale della prossima generazione di servizi pubblici.