La PDND e l’interoperabilità utile

Il sistema informativo di una pubblica amministrazione è un oggetto complesso e articolato, da più punti di vista. Al livello infrastrutturale si affiancano quello sistemistico, quello applicativo, quello dei dati e poi le misure di sicurezza e i dispositivi per implementarle. Ci sono le procedure operative per mantenerlo efficiente e tenerlo sotto controllo ecc.

Credo che sia molto difficile, se non impossibile, che un’unica persona riesca a dominare e governare con piena consapevolezza e responsabilità, da solo, tutti gli aspetti sopra confusamente e parzialmente elencati.

Figuriamoci, allora, il disorientamento di chi si approccia al sistema informativo con lo sguardo principalmente orientato alla dimensione applicativa, alle funzioni che il sistema è in grado di offrire per realizzare, con processi ben orchestrati, le finalità dell’organizzazione stessa, in una cornice di conformità e correttezza giuridico-amministrativa, possibilmente ottimizzando le risorse a disposizione.

Con questa prospettiva, poi, gli occhi brillano di fronte a un sistema informativo che è in grado di condividere, sia internamente che esternamente, dati e funzioni applicative e, così, di far circolare informazione. Questa caratteristica è una delle tante declinazioni del termine interoperabilità, che, nel periodo attualmente vissuto dalla pubblica amministrazione italiana fa decisamente rima con PDND, la Piattaforma Digitale Nazionale Dati.

Come in un percorso di ricerca e formazione, vorrei qui provare a orientarmi nel dedalo di cosa effettivamente serve per sfruttare al meglio PDND e interoperabilità, cosa è essenziale e cosa è accessorio, cosa è fortemente raccomandato e cosa, invece, sia da evitare. Il punto di vista è principalmente quello del fruitore di servizi digitali.

L’esperienza diretta

Mosso da un istinto sperimentale, un paio di anni fa, ho provato in prima persona a realizzare, da zero o quasi, degli strumenti di base, primitivi ma didattici, che consentissero di dialogare con alcuni servizi digitali messi a disposizione da altre amministrazioni attraverso la PDND. Ne sono usciti due risultati:

• parlaConINAD, che recupera i domicili digitali anche massivamente a partire da un file CSV e
• parlaConANPR, che si interfaccia con l’Anagrafe Nazionale della Popolazione Residente per accertare (consultare) i dati di residenza o dello stato di famiglia di una persona.

I risultati finali realizzano in modo completo – e, a mio modo di vedere, corretto – l’interazione informatica con le banche dati INAD e ANPR, intermediata dalla PDND.

L’esperienza mi ha consentito di guardare da vicino i livelli coinvolti per realizzare l’interazione e dare concretezza ad alcuni concetti che, con la sola lettura di guide e specifiche, sono fumosi o sfuggenti. Mi ha anche consentito di concludere che allestire un processo interoperabile non riguarda solo l’interrogazione del sistema remoto, ma coinvolge anche aspetti che lo precedono e lo seguono e che richiedono una visione completa sul processo stesso.

Il funzionamento tecnico della PDND e gli scambi interoperabili

Premetto, a mo’ di disclaimer^[1]In italiano: per “mettere le mani avanti”., che potrei non avere nel seguito una terminologia eccessivamente rigorosa dal punto di vista tecnico, ma cerco di spiegare nel modo più semplice, restando nei limiti della correttezza, quanto ho appreso e sperimentato.

Nel seguito ci si pone nella situazione in cui:

• l’adesione alla PDND è completata;
• si è concluso l’accordo di fruizione di un e-service;
• si è definita la finalità della fruizione dell’e-service.

Autenticazione e sicurezza

Qualsiasi interazione intermediata dalla PDND ha un livello di autenticazione e sicurezza, mutuato dal ModI (il Modello per l’Interoperabilità tecnica delle pubbliche amministrazioni), che si ripete sempre uguale, indipendentemente dal dominio applicativo o di conoscenza in cui si pone il dialogo interoperabile, dalla materia dei dati o delle funzioni condivise. In definitiva, per fruire di un qualsiasi servizio digitale messo a disposizione da un erogatore occorre farsi riconoscere e garantire, in qualche misura, integrità e riservatezza degli scambi.

E-service, client e materiale crittografico

L’e-service (o servizio digitale) è la componente informatica allestita dall’erogatore, che funge da punto di accesso ai dati o alle funzioni applicative che l’erogatore decide di mettere in condivisione e resta in attesa di essere contattata da un soggetto esterno (il fruitore) che intende interagire con quei dati o quelle funzioni.

Per consentire l’interazione, l’e-service mette a disposizione un’interfaccia API (Application Programming Interface) che consente di ricevere le richieste del fruitore e fornire le relative risposte, secondo regole formali condivise. Tali regole sono definite e dettagliate nel documento di specifiche API.

L’e-service, quindi, si occupa di riconoscere il soggetto esterno, ricevere la sua richiesta e fornirgli una risposta. Secondo il ModI, ciò avviene principalmente utilizzando le tecnologia REST o SOAP, entrambe veicolate dal protocollo di trasferimento HTTP, lo stesso del world wide web. In accordo con il protocollo HTTP, l’interazione di base si compone di una request, che il fruitore invia all’erogatore, e di una response, che segue il percorso inverso. I contenuti informativi, solitamente, sono scambiati all’interno di documenti in formato JSON o XML, veicolati nel payload (contenuto) degli scambi HTTP.

Prima di interagire con un e-service pubblicato su PDND occorre che un utente PDND con ruolo di amministratore per il fruitore, allestisca un client e-service e vi abiliti eventuali altri utenti come membri. Il client e-service consente, agli utenti che ne sono membri, di reperire tutte le informazioni necessarie per contattare un e-service per una data finalità e, soprattutto, di depositarvi le chiavi pubbliche associate alle chiavi private che si useranno per cifrare alcune parti dei successivi scambi interoperabili. Per questo, il client e-service è anche detto “contenitore di materiale crittografico“.

L’autenticazione mediata dalla PDND

Per autenticarsi su un e-service pubblicato sula PDND, il metodo di base, comune a tutti, è richiedere alla PDND un “voucher“, da spendere poi nelle chiamate all’e-service, inserendolo nell’intestazione della request HTTP, secondo le regole formalizzate dal ModI con il pattern di sicurezza [ID_AUTH_REST_01].

Il voucher, che tecnicamente è un token JWT, si ottiene dopo aver inviato alla PDND una client assertion in formato JWS, firmata con una chiave privata. La client assertion contiene, fra le altre, informazioni su:

• l’e-service che si vuole contattare e la finalità del contatto (precedentemente definita, ha un suo codice identificativo);
• l’identificativo del client e-service che contiene la chiave pubblica corrispondente alla chiave privata usata per firmare;
• l’identificativo della chiave pubblica.

Il rilascio del voucher avviene a seguito di un’interazione di tipo REST. La PDND riconosce il soggetto che richiede il voucher perché la client assertion è firmata con la chiave privata che solo il soggetto può conoscere e gli rilascia il voucher. Il voucher è un token JWT (una stringa alfanumerica, di fatto) che il fruitore deve inserire nelle intestazioni delle sue richieste all’erogatore. Il tecnicismo che il voucher è inserito come valore della chiave “Authorization”, preceduto dal prefisso “Bearer”, qui poco rileva. Rileva, invece, osservare che il trust fra fruitore ed erogatore è avvenuto tramite la PDND. L’erogatore non ha necessità di censire o accreditare utenti fruitori sui propri sistemi ma si limita a verificare la validità del voucher rilasciato dalla PDND, controllando la sua firma e le informazioni di autenticazione che contiene. La verifica che il fruitore sia autorizzato ad accedere al sistema avviene a monte, quando la PDND rilascia (o non rilascia) il voucher.

L’integrità e la provenienza del contenuto mediati dalla PDND

Il ModI prevede, facoltativi, da valutare in base alla criticità delle operazioni consentite dall’e-service, ulteriori meccanismi di sicurezza.

Per esempio, gli e-service di ANPR (Anagrafe Nazionale della Popolazione Residente) richiedono:

• di garantire l’integrità del messaggio di richiesta, secondo il pattern ModI [INTEGRITY_REST_02]: in sintesi, nell’intestazione della richiesta si riporta anche l’impronta (hash) del contenuto della richiesta (payload) cifrata con la solita chiave privata usata per ottenere il voucher;
• di fornire dati tracciati nel dominio del fruitore, secondo il pattern ModI [AUDIT_REST_02]: in sintesi, il fruitore fornisce informazioni sul suo ambiente informatico e sull’operatore che scatena la richiesta di fruizione del servizio. Anche queste informazioni sono firmate dal fruitore, tramite un processo che coinvolge anche la PDND^[2]In realtà, nel caso di ANPR, la dichiarazione dei dati tracciati nel dominio del fruitore interviene anche nella richiesta iniziale del voucher alla PDND, per questo di parla di … Continue reading.

Il livello del contenuto informativo

Se per le parti di autenticazione e sicurezza, la cosiddetta “interoperabilità tecnica” esistono delle regole standard, codificate nel citato ModI, altrettanto non si può dire per il contenuto informativo. Non esistono, infatti, regole (sintattiche e semantiche) per mettere insieme i dati di cui si compongono richieste e riposte.

Solitamente, il contenuto è veicolato tramite formati JSON o XML, brani di testo semplice, con specifiche regole sintattiche che consentono di dare ai dati una struttura ordinata e elaborabile da un calcolatore, tramite le chiavi o i tag. Non ci sono però regole condivise su come scrivere il contenuto informativo: fin tanto che si tratta di consultare una banca dati centrale non ci sono problemi, la banca dati definisce una API e tutti vi si adeguano. Si tratta al più di stabilire delle corrispondenze fra le etichette che la banca dati centrale assegna a un certo dato e quelle che si usano nel proprio sistema informativo. Quando invece si vogliono recuperare dati omogenei, della stessa natura, da fonti diverse potrebbe darsi il caso che ogni erogatore abbia definito una API diversa, per sintassi e per semantica.

Al di là di questa distinzione, quando si intende inserire un’interazione con una fonte esterna in un proprio processo è importante comprendere quali dati occorrono per avanzare la richiesta, quali dati si ricevono in risposta e come interpretarli. Analizzare il documento di specifica API guida in questo compito. Tuttavia, non sempre le specifiche pubblicate sulla PDND sono sufficientemente esaustive o chiare: non sempre è chiaro il significato di un certo dato o il formato con cui è trasmesso. Non sempre, poi, le specifiche API sono accompagnate da documentazione narrativa che le completano.

Questione di processo

Si è visto che l’API di ANPR richiede come dato in ingresso il “practicalreference”, cioè un riferimento puntuale a una pratica gestita dal fruitore che genera l’esigenza e la base giuridica per l’interrogazione. Se inserito in un flusso automatico, allora, il contatto con ANPR va pensato in un momento in cui si ha a disposizione almeno un identificativo univoco del motivo dell’interrogazione. Tramite questo, infatti, sarà possibile risalire alla motivazione che ha spinto a richiedere dei dati. Se invece l’interazione con ANPR tramite e-service è del tutto manuale, occorre che l’operatore inserisca una motivazione con un riferimento univoco, senza cedere a tentazioni semplicistiche di fornire generiche giustificazioni tipo “verifica anagrafica”^[3]E grazie – direbbe ANPR se solo potesse parlare -, che stai facendo una visura anagrafica lo vedo anche io. Vorrei sapere perché, non è che puoi fare interrogazioni così, acausali..

Ci si può però chiedere se utilizzare gli e-service di ANPR per creare maschere di consultazione libera risponda allo spirito dell’interoperabilità e ai principi in base ai quali il ministero ha deciso di aprire i dati agli enti pubblici (e, in alcuni casi, anche ai privati): non è che la consultazione libera favorisce eccessivamente interrogazioni abusive? Qualcosa al riguardo avevo detto qui.

L’interoperabilità utile

Del resto, se le banche dati nazionali volessero essere consultate a cuor leggero avrebbero pubblicato delle pagine web per consultazioni libere riservate a personale di enti pubblici accreditati. Va da sé che il vero valore dell’interoperabilità dei dati – e occorre porselo come obiettivo – si ottiene quando l’interoperabilità c’è ma non si vede, quando in modo del tutto trasparente si accede a un dato da un proprio sistema senza accorgersene (cioè, senza aprire nuove maschere, senza inserire dati già inseriti altrove ecc.).

Per raggiungere l’obiettivo, già adesso è importante capire in quale punto del flusso di lavoro inserire l’interazione con gli e-service di consultazione dei dati. Nel caso dei servizi online, per esempio, c’è la possibilità di contattare e-service per recuperare dati da fonti autorevoli già in fase di compilazione di un’istanza o di una comunicazione. In questo modo si supera il modello di verifica delle autodichiarazioni tipiche dell’attivazione analogica dei servizi e si passa una sorta di “acquisizione d’ufficio in tempo reale“. Si possono anche prevedere dei controlli bloccanti per cui, se certe condizioni non sono soddisfatte, non è nemmeno possibile inviare l’istanza o la comunicazione (per esempio, se il valore ISEE supera una certa soglia).

Il vantaggio è evidente, perché si riducono gli oneri istruttori. Tuttavia occorre progettare bene questo tipo di interazione e porsi delle domande di compliance: si deve informare in qualche modo l’utente connesso del fatto che si sta facendo una visura automatica di una sua situazione? Se l’API utilizzata richiede il riferimento della persona fisica che ha avviato l’interrogazione, chi si indica? Se richiede un riferimento puntuale a una pratica in corso, quale identificativo si usa e come ci assicuriamo di essere in grado di ricostruire la storia dell’interrogazione dell’e-service in caso di necessità?

Niente di insormontabile, ma sono tutte questioni degne di nota e per le quali, purtroppo, non esistono posizioni e prassi condivise, forse perché l’interesse verso i servizi online si focalizza soprattutto sulla parte di esperienza dell’utente.

Anche l’e-service di INAD impone qualche considerazione sul punto del flusso in cui attivare l’interazione. Le indicazioni delle linee guida di INAD sono chiare: il domicilio digitale va recuperato solo al momento dell’invio per essere sicuri di trattare un dato esatto e non inviare male (principio di esattezza) e non va memorizzato in anagrafiche locali (principio di limitazione della conservazione e rischio di usare poi un dato non aggiornato). Il momento in cui fare la ricerca è chiaro. Tuttavia, emerge un’altra questione: quale componente del sistema informativo effettua la richiesta? Se in una pubblica amministrazione le comunicazioni partono dal sistema di gestione documentale, conviene che sia sempre il sistema di gestione documentale a recuperare il domicilio digitale o, nel caso in cui il documento in partenza sia prodotto da una componente distinta, sia questa a richiederne registrazione e invio fornendo il domicilio digitale estratto da INAD?

In definitiva, come già anticipato non è solo questione di stabilire il canale per scambiarsi dati con l’erogatore. Quello, alla fine, è un compito tecnico che si riesce a svolgere senza eccessive difficoltà, come dimostrano anche le citate esperienze artigianali di parlaConANPR e parlaConINAD.

Questione tecnica

Si ripete spesso che la trasformazione digitale non è solo una questione tecnica, proprio perché riguarda la revisione complessiva dei processi. Tuttavia la componente tecnica. cioè quella che richiede una conoscenza specifica specializzata su alcuni aspetti di funzionamento degli strumenti, è ineliminabile e la PDND non fa eccezione. Oltre ai “tecnicismi” della programmazione di e-service e di servizi di consultazione di e-service, già la gestione della presenza dell’ente fruitore sulla PDND richiede conoscenze e accorgimenti tecnici.

Gestire gli utenti PDND

Per gli enti fruitori, la PDND prevede due ruoli^[4]L’allegato 2 delle linee guida prevede, in realtà, cinque ruoli: rispetto a quelli segnalati ne sono menzionati due – “Operatore consultazione” e “Operatore … Continue reading con differenti permessi:

• l’amministratore, che tutto può (incluso fare accordi di fruizione e definire finalità) e
• l’operatore di sicurezza che, invece, accede solo ai client e-service di cui è membro per recuperare le informazioni necessarie a contattare un e-service e per depositare le chiavi pubbliche.

Se si ha presente il funzionamento tecnico della PDND e i meccanismi di autenticazione agli e-service, dovrebbe risultare evidente che il ruolo di amministratore va attribuito con grande parsimonia^[5]Non a caso la PDND prevede che ogni ente aderente possa avere al massimo tre amministratori..

Diventa dunque fondamentale che anche per le organizzazioni con un reparto IT non sviluppato (o assente) presidiare con attenzione la presenza del proprio ente sulla PDND.

Anche se la questione non è trattata nella documentazione ufficiale, la strada più saggia e sostenibile è quella di avere uno o più amministratori fra i dipendenti ed istruirli per:

• attivare accordi di fruizione o pubblicare e-service (come erogatore);
• pubblicare finalità (come fruitore);
• creare client e-service (come fruitore) o portachiavi (come erogatore);
• associare le finalità ai client e-service;
• abilitare utenti al client e-service come operatori di sicurezza e agli e-service come operatori API,

in modo che possano creare uno spazio dedicato per ogni soggetto esterno (fornitore) che sviluppa connettori o e-service per l’amministrazione. In questo modo si evitano interferenze e non ci sono sovrapposizioni di responsabilità. Niente vieta, ovviamente, che l’amministratore interno si avvalga di un supporto esterno (un consulente ad hoc o anche lo stesso fornitore che sviluppa connettori o e-service), ma resta fondamentale essere consapevoli di cosa avviene.

Gestire le interrogazioni interoperabili: il gateway API

Poiché la parte di interoperabilità tecnica mediata dalla PDND è praticamente standardizzata dal ModI, motivi di razionalità potrebbero imporre di non implementare il dialogo interoperabile tramite PDND in ogni componente del sistema informativo che necessita di interagire con un e-service PDND. Potrebbe essere più conveniente centralizzare quelle operazioni e affidarsi a un gateway API. Il gateway API è un’ulteriore componente del sistema informativo che può venire in aiuto tanto a chi eroga e-service quanto a chi ne fruisce. La questione è articolata e, per questo, le dedicherò a breve un post a parte.

Questione documentale

La possibilità di accedere alle informazioni direttamente alla fonte, in modo immediato (nel duplice senso dell’assenza di lassi di tempo significativi fra domanda e risposta e dell’assenza di intermediari) e anche in chiave retrospettiva, potendo fare ricerche relative a momenti del passato, abilita nuove possibilità e impone delle riflessioni sulle modalità con cui documentare le proprie azioni.

In altri termini, la PDND cambia il modo con cui si accede all’informazione. Cambia, allora, il modo con cui si documentano le azioni e i processi decisionali: cambia, dunque, anche l’archivio?

Più viste, meno certificati

Tradizionalmente, la verifica di un’autocertificazione o l’acquisizione d’ufficio di un dato si sostanziano in uno scambio di corrispondenza (necessariamente asincrono) fra il soggetto che ha bisogno di verificare un’informazione e quello che ha la capacità di certificarla perché la detiene.

Con la PDND, le richieste di verifica e le relative risposte diventano un flusso di dati, che poi viene interpretato da un sistema che lo rende intellegibile all’operatore o, in situazioni di automazione più spinta, lo elabora autonomamente. Detto che, a livello tecnico-teorico, in realtà, niente vieterebbe al soggetto certificante di rispondere con un documento più tradizionale (per esempio, un PDF/A dotato di sigillo elettronico qualificato), nei fatti la risposta resta un flusso di dati. Si pone allora il problema di come documentalizzare la risposta e “acquisirla agli atti”. Però, riflettendoci, è davvero necessario replicare lo schema tradizionale della registrazione in archivio del “certificato” prodotto dal soggetto certificante, quando in qualunque momento è possibile ottenere la stessa informazione, anche andando a ritroso nel tempo?

Non basterebbe, allora, dare atto nei proprio atti istruttori o nei documenti finali, della vista (o visura) eseguita direttamente alla fonte? Magari annotando qualche dato identificativo della ricerca eseguita, quale il momento di richiesta e risposta o l’identificativo dell’interrogazione che non manca mai.

Fra l’altro, vale la pena sottolineare che le riposte che si ricevono dagli erogatori non sono firmate, almeno quelle degli e-service più diffusi e delle banche dati centrali (come ANPR, INAD o ISEE). In realtà, la firma sarebbe tecnicamente possibile: come si firmano le richieste secondo il pattern [INTEGRITY_REST_02], così si potrebbero firma le risposte. Infatti, anche la PDND prevede per gli erogatori i “portachiavi“, degli analoghi dei client e-service per depositare e rendere disponibili le chiavi pubbliche per verificare eventuali firme.

Quindi, se ci si vuole impegnare nell’avventura di documentalizzare le risposte ricevute da e-service PDND, occorre anche trovare un modo per collegare con certezza il documento prodotto all’interazione con l’e-service e garantire che il contenuto del documento coincida con il flusso di dati, che sia integro e di provenienza certa.

Un nuovo rapporto con i principi della protezione dei dati personali

Il superamento dell’archiviazione di certificati, spesso con dati sovrabbondanti, consente anche di guardare con occhio diverso alcuni dettami della protezione dei dati personali e dare vera e sostenibile attuazione a quei sacrosanti principi da ultimo scolpiti nel GDPR, ma presenti già da tempo nella cultura e nella normativa italiana ed europea in genere: trattare solo dati pertinenti e non eccedenti, la minimizzazione del trattamento, la limitazione della conservazione ecc.

Per dare una concretezza all’idea: se devo verificare che una persona ha due figli non ho bisogno di custodire nel mio archivio un certificato completo dello stato di famiglia, che porta con sé i dati anagrafici di altri soggetti di cui non ho bisogno. Basta dare atto della ricerca fatta e del suo esito, annotando l’identificativo della transazioni interoperabile, che, specifiche API alla mano è il primo dato contenuto nel JSON di risposta, sotto la chiave “idOperazioneANPR“.

A tendere, poi, sarebbe anche utile che le grandi banche dati offrissero servizi digitali per verificare una condizione o un requisito senza acquisire dati puntuali e superflui. Per esempio, fornire l’informazione se qualcuno ha più di due figli, oppure un valore ISEE inferiore a un valore soglia: basta una risposta del tipo “sì o no”, senza bisogno di fornire troppi dettagli.