AgID rivisita il protocollo interoperabile: cogliamo l’occasione per la vera interoperabilità?

L’Agenzia per l’Italia Digitale (AgID) ha annunciato che rivisiterà l’allegato 6 delle linee guida sul documento informatico, anche sull’onda dell’hype creatosi intorno alla PDND e al collegato avviso PNRR e al fatto che l’interoperabilità di protocollo è fra i cinque casi d’uso individuati dal Dipartimento per la trasformazione digitale per i quali i comuni italiani dovrebbero diventare erogatori di interfacce API tramite la PDND.

L’annuncio mette in primo piano l’esigenza di passare da tecnologia SOAP a tecnologia REST. C’è da sperare che la revisione non si limiti a questo. Indipendentemente dalla tecnologia usata^[1]Sì, ok, le API REST sono molto molto molto più facili da implementare e quasi quasi ci si interagisce bene anche con un solo browser web…, ci sono problemi aperti, sia nell’attuale impostazione logica dell’interazione fra protocolli informatici per la trasmissione di messaggi, sia, soprattutto, per l’interoperabilità interna, cioè per trasferire nel sistema di gestione documentale i documenti prodotti da procedure software interne all’amministrazione. Tanto che si potrebbe anticipare un commento conclusivo:

Se l’Agenzia per l’Italia Digitale non ha intenzione di cogliere l’occasione della rivisitazione dell’allegato 6 per mettere mano alla questione dell’interoperabilità interna con il sistema di gestione documentale, l’intera operazione rischia di rilevarsi piuttosto inutile.

Saltiamo i preamboli su cosa sono l’allegato 6, il protocollo interoperabile e la segnatura XML (qui alcuni post al riguardo).

Come funziona oggi

Oggi come oggi è teorizzata la possibilità di usare web service per scambiarsi messaggi fra AOO^[2]AOO sta per Area Organizzativa Omogenea, di fatto un ente pubblico. ma mancano le condizioni tecnologico-organizzative di contorno per renderlo possibile^[3]Come accennato, la nascita della PDND – Piattaforma Digitale Nazionale Dati, potrebbe essere un tassello per creare le condizioni. Ma non l’unico.. Quindi, oggi come oggi, il protocollo interoperabile funziona tramite PEC. Il protocollo destinatario elabora la segnatura XML allegata alla PEC ai fini della protocollazione del messaggio.

Una registrazione di protocollo non presidiata?

Sarebbe possibile una registrazione a protocollo non presidiata per un messaggio interoperabile? Tecnicamente sì, nella pratica no (e nemmeno nella teoria^[4]Ogni organizzazione ha le sue regole di gestione documentale: banalmente, anche delle sue convenzioni per scrivere l’oggetto che descrive il contenuto un documento/messaggio. Per sottolineare … Continue reading). Infatti, nella pratica, i dati contenuti nella segnatura XML vanno ripuliti e integrati: l’oggetto contiene spesso un riferimento al numero di protocollo mittente (che non ha senso che stia lì), occorre assegnare per competenza e/o conoscenza il messaggio alle corrette unità organizzative (uffici), classificare e fascicolare ^[5]Qui si potrebbe aprire una discussione infinita: in quale fase si classifica, in quale si fascicola, La classificazione è intrinseca al documento? Fatto sta che prima o poi sono operazioni da fare e … Continue reading. A volte anche sistemare il mittente, che riesce a non presentarsi bene.

Insomma, occorre l’intervento dell’operatore per superare sia dei limiti intrinseci del sistema, sia per rimediare a imprecisioni del mittente.

Certo, limiti intrinseci e imprecisioni si potrebbero superare anche aumentando ordine e controlli tecnici: tenere aggiornato l‘organigramma degli uffici sull’Indice PA e collegarlo a un catalogo dei procedimenti potrebbe guidare l’assegnazione per competenza di un messaggio in arrivo, per esempio.

Quindi: il passaggio a REST da solo, migliora la precisione e consente di sveltire, se non automatizzare, le operazioni di registrazione?

File grandi e ingenerosa svalutazione della PEC

La PEC è – a mio modo di vedere ingenerosamente e ingiustamente – avversata per due motivi principali che i suoi detrattori cavalcano costantemente:

• ha limiti alla dimensione dei file che veicola come allegati;
• trasmette dati non strutturati e non riusabili.

Sul primo punto già l’attuale allegato 6 fornirebbe dei rimedi: veicolare tramite segnatura XML un link sicuro, protetto da credenziali valide per un periodo limitato, che punti al file troppo grande per essere infilato nella PEC. Non una prassi consolidata nella p.a., non una feature che le software house offrono (di serie). Fra l’altro, lo stesso escamotage si può usare fra terminali della comunicazione non enti pubblici: una bella lettera di accompagnamento e “il file X è troppo grande, lo trovi a questo LINK, ha impronta I, le credenziali per accedere sono C e D e valgono per N giorni”.

La critica di cui al secondo punto, invece, è proprio mal indirizzata: non può essere rivolta al canale di trasmissione ma al contenuto. Anche tramite un web service posso trasmettere la digitalizzazione di un documento compilato a penna con grafia incerta. Un file JSON pieno di dati strutturati può essere inviato anche tramite PEC.

La PEC – con la sua epigona REM e i vari SERCQ^[6]SERCQ sta per Servizio Elettronico di Recapito Certificato Qualificato: è una teorizzazione del regolamento europeo eIDAS che serve a individuare uno strumento di comunicazione telematica sul quale … Continue reading – ha comunque il vantaggio che, oltre a essere universale, cioè a funzionare tanto nei confronti di privati quanto nei confronti di pubbliche amministrazioni, è una comunicazione valida, opponibile a terzi, con contenuto e date di accettazione e consegna certe, proprio per l’intervento di un soggetto terzo autorevole.

Il web service REST per la comunicazione fra AOO quindi:

• supererebbe il limite alla dimensione dei file, ma solo fra AOO, quando di solito è il privato (leggi progetti di edilizia) invischiato nella trasmissione di file pesanti;
• richiederebbe, tuttavia, nuove sensibilità, espedienti tecnici e strumenti di validazione per valutare l’attendibilità della comunicazione^[7]Non che adesso sia prassi diffusa, ma il messaggio PEC completo esportato e salvato in formato .eml ha tutto ciò che serve per essere apprezzato nella sua autorevolezza, sotto il profilo di … Continue reading.

Di nuovo, se il vantaggio del passaggio al web service (SOAP o REST che sia) si limita a spostare file grandi fra pubbliche amministrazioni… ne vale la pena?

Ulteriore chiosa, a rischio di apparire uno che gioca con le parole: la PEC, alla fine, è un messaggio e-mail. Cosa esiste di più interoperabile del sistema di messaggistica e-mail? C’è uno standard internazionale che esiste praticamente da quando esiste Internet. Ci sono un numero impressionante di server e-mail che funzionano ciascuno con tecnologie diverse, ancora più numerosi sono i domini e-mail. Esiste un linguaggio universale per farli parlare. Possiamo scrivere e leggere e-mail da una quantità esorbitante di client: non solo software diversi su un PC, non solo pagine web messe a disposizione dal gestore della casella (webmail), ma anche dispositivi di ogni tipo, smartphone e tablet, ma anche frigoriferi e televisori smart. Ci devono quindi preoccupare gli aspetti tecnici (protocolli di trasmissione) della trasmissione di messaggi fra soggetti distinti? Forse, dobbiamo pensare più ai contenuti…

L’interoperabilità interna

Web service e API fanno rima con interoperabilità. L’interoperabilità di cui però gli enti pubblici hanno bisogno come il pane è l’interoperabilità interna. Qui si sta parlando di scambio di messaggi con documenti allegati e quindi parliamo di interoperabilità con il sistema di gestione documentale. Agli enti serve poter registrare nel sistema di gestione informatica dei documenti, in modo automatico e trasparente all’utente che usa un software gestionale, i documenti prodotti e ricevuti, per conferire loro valore giuridico-probatorio, per ritrovarli, per formare il fascicolo che tiene insieme documenti formati o ricevuti tramite sistemi diversi ecc.

Sono noti casi in cui l’attuale impostazione del protocollo interoperabile è usata per trasferire a protocollo documenti formati o ricevuti da un altro pezzo del sistema informativo dell’ente. E’ un po’ una forzatura, ma funziona. Servono degli accorgimenti: il software usa una casella PEC ben identificata e dedicata esclusivamente a quello scopo, il protocollo informatico deve essere in grado di registrare automaticamente un messaggio interoperabile che arriva da quella casella (e solo da quella), occorre concordare ulteriori tag XML per gestire correttamente il messaggio a livello documentale (smistamenti, classe, fascicolo, comunicazioni per conoscenza, note di trasmissione ecc.).

Uno strumento per scambi esterni è adattabile a scambi interni?

Tolta la forzatura appena descritta, è evidente che uno strumento pensato per spedire un messaggio a un soggetto esterno ha alcune peculiarità che non lo rendono adatto a usi interni. In particolare, il protocollo interoperabile come pensato oggi:

• è asincrono, nel senso che il destinatario elabora il messaggio non contestualmente al suo ricevimento, ma in un secondo momento (v. sopra);
• non si preoccupa di avviare la gestione interna del documento trasmesso (v. sopra).

Tuttavia, una revisione delle attuali regole che vada oltre il passaggio da tecnologia SOAP a tecnologia REST, potrebbe superare questi limiti.

Qualcosa da rivedere anche per l’interoperabilità esterna

Poi, ben inteso, qualcosa da aggiustare anche per l’interoperabilità esterna c’è. Cito due situazioni estratte dalla limitata esperienza personale:

• non appare del tutto ragionevole che la segnatura debba essere creata al momento della registrazione, poiché concettualmente registrazione e trasmissione sono due momenti distinti ed esistono situazioni pratiche del tutto fisiologiche in cui la distinzione dei momenti si realizza in concreto. Inoltre la registrazione è, con le dovute accortezze, modificabile ma, a conti fatti, non la segnatura;
• c’è un po’ di confusione sui metodi pratici per rappresentare le impronte in formato BASE64.

Ma questa è un’altra storia, tutto sommato marginale: anche se si potrebbe anche ragionare serenamente se e quanto abbia senso, con l’uso della PEC, che una non conformità tecnica a un meccanismo di scambio di messaggi fra una limitata categoria di corrispondenti, fra l’altro sottoutilizzato, possa generare un rifiuto perentorio di un messaggio che magari porta con sé file firmati digitalmente dentro una busta di trasporto autorevole e che garantisce integrità e certezza di provenienza e tempi.

La PDND è adeguata?

L’impostazione attuale della PDND prevede che questa, fra l’altro, si faccia carico di concludere e gestire gli accordi di fruizione:

• ogni ente (erogatore) che espone un’API la pubblica sul catalogo;
• ogni ente che vuole fruirne avanza una richiesta tramite PDND;
• l’ente erogatore approva o rifiuta la richiesta di fruizione;
• dove il criterio di approvazione si basa solo su attributi qualificati la PDND consente di automatizzare l’approvazione/rifiuto^[8]Questo meccanismo è teorizzato ma non è chiaro se sia operativo: io personalmente, in ambiente di test, ho fatto richiesta di fruizione di alcuni servizi di questo tipo e sono ancora in attesa di … Continue reading.

Nel caso del protocollo interoperabile, ipotizzando che le AOO siano ventimila (8.000 comuni circa, altrettante scuole), avremmo:

• un catalogo illeggibile^[9]Secondo la lettura di alcuni, forse ingolositi dal contributo PNRR, il protocollo interoperabile non darebbe luogo a un solo “e-service” – il nome che le API esposte hanno nella … Continue reading;
• un reticolo di accordi di fruizione altrettanto ingestibile;
• la necessità pe ogni ente di creare ventimila “client e-service” PDND^[10]Il “client e-service” è un oggetto che l’ente fruitore deve creare per ogni e-service del quale intende fruire per gestire lo stacco del voucher / token JWT che gli servirà per … Continue reading

Una rivisitazione del modello di autorizzazione è senz’altro necessaria. Una proposta la avrei: l’adesione formale si fa alla generica API “protocollo interoperabile”, esposta magari da AgID o altro soggetto nazionale come “nodo centrale” (anche la PDND o PagoPA spa stesse); questo soggetto fa in qualche modo da proxy o da router, insomma, dirige e incanala il traffico sulla base del codice AOO del destinatario. Nelle definizioni attuali l’ente che vuole usare (come mittente o destinatario) il protocollo interoperabile tramite web service è il fruitore dell’API, il soggetto centrale è l’erogatore. Un solo client “e-service”, un solo accordo, una sola definizione di API (e non ventimila ripetute uguali identiche, a meno di errori).

Conclusioni

La conclusione è già stata anticipata all’inizio: se la rivisitazione in chiave REST dell’interoperabilità di protocollo non viene colta come occasione per dare slancio a uno standard anche per l’interoperabilità interna, vuol dire che, probabilmente, la gestione documentale è davvero un’attività negletta, dimenticata anche da chi, come l’Agenzia per l’Italia Digitale, ne dovrebbe dettare gli indirizzi come missione istituzionale.

Gli ingredienti per arrivare a una soluzione, o almeno per avviare lo studio e ragionarci su, ci sono tutti:

• l’esperienza di protocollo interoperabile secondo l’allegato 6 ma anche e soprattutto secondo la precedente circolare 60 del 2013;
• i metadati di documenti e aggregazioni documentali, definiti nell’allegato 5 alle linee guida sul documento informatico;
• la PDND che, opportunamente adeguata, può fare da nodo smistatore per le migliaia di AOO coinvolte da scambi di messaggi.

Se c’è la volontà di portare il documento al centro, di occuparsi – senza intromissioni nell’autonomia organizzativa – anche di ciò che avviene “dentro le mura” delle amministrazioni, allora c’è anche la disponibilità di chi opera sul campo a portare un contributo. Il desiderio di condividere e contribuire c’è, diffuso. Altrettanto presente e diffusa è la sensazione di fare duelli con i mulini a vento.

Foto di Gerd Altmann da Pixabay