Linee Guida sull’infrastruttura tecnologica della Piattaforma Digitale Nazionale Dati per l’interoperabilità dei sistemi informativi e delle basi di dati¶
Consultazione pubblica
La consultazione pubblica per questo documento è attiva dal 04/10/2021 al 03/11/2021.
Questo documento raccoglie il testo delle Linee Guida sull’infrastruttura tecnologica della Piattaforma Digitale Nazionale Dati per l’interoperabilità dei sistemi informativi e delle basi di dati, e dei relativi Allegati, disponibile per la consultazione pubblica.
Leggi le istruzioni per la consultazione
Linee Guida sull’infrastruttura tecnologica della Piattaforma Digitale Nazionale Dati per l’interoperabilità dei sistemi informativi e delle basi di dati¶
ai sensi dell’articolo 50-ter, comma 2 del CAD
Introduzione¶
Nell’ambito del modello di interoperabilità delle pubbliche amministrazioni (di seguito MoDI), le presenti Linee Guida (di seguito Linee Guida) concernono la Piattaforma Digitale Nazionale Dati (di seguito PDND) di cui all’articolo 50-ter del decreto legislativo 7 marzo 2005, n. 82 e s.m.i. recante il “Codice dell’amministrazione digitale” (di seguito CAD), avendo ad oggetto l’infrastruttura tecnologica per l’interoperabilità dei sistemi informativi e delle basi di dati (di seguito Infrastruttura interoperabilità PDND) di cui al comma 2 del medesimo articolo.
Ai sensi dell’articolo 50-ter, comma 1 del CAD, la PDND è finalizzata a favorire la conoscenza e l’utilizzo del patrimonio informativo detenuto per finalità istituzionali dai soggetti di cui all’articolo 2, comma 2 del CAD nonché la condivisione dei dati tra i soggetti che hanno diritto di accedervi ai fini dell’attuazione dell’articolo 50 del CAD e della semplificazione degli adempimenti dei cittadini e delle imprese, in conformità alla disciplina vigente.
Ai sensi dell’articolo 50-ter, comma 2 del CAD, l’Infrastruttura interoperabilità PDND rende possibile l’interoperabilità dei sistemi informativi e delle basi di dati dei soggetti interessati, mediante:
- l’accreditamento, l’identificazione e la gestione dei livelli di autorizzazione dei soggetti abilitati a operare sulla stessa;
- la raccolta e la conservazione delle informazioni relative agli accessi e alle transazioni effettuati suo tramite.
Ai sensi dell’art. 50-ter, comma 2-bis, del CAD, il Presidente del Consiglio dei Ministri o il Ministro delegato per l’innovazione tecnologica e la transizione digitale, ultimati i test e le prove tecniche di corretto funzionamento della Infrastruttura interoperabilità PDND, fissa il termine entro il quale i soggetti di cui all’articolo 2, comma 2, del CAD saranno tenuti ad accreditarsi alla stessa, a sviluppare le interfacce e a rendere disponibili le proprie basi dati.
Nel rispetto dell’art. 50-ter, comma 7, del CAD, resta inteso che i soggetti di cui all’articolo 2, comma 2, del CAD possono continuare a utilizzare anche i sistemi di interoperabilità già previsti dalla legislazione vigente, ossia i sistemi di interoperabilità esistenti prima dell’introduzione della normativa che ha istituito la Piattaforma Digitale Nazionale Dati.
Le Linee Guida sono emanate ai sensi dell’articolo 50-ter, comma 2, ultimo periodo del CAD, che dispone quanto segue: “L’AgID, sentito il Garante per la protezione dei dati personali e acquisito il parere della Conferenza unificata, di cui all’articolo 8 del decreto legislativo 28 agosto 1997, n. 281, adotta linee guida con cui definisce gli standard tecnologici e criteri di sicurezza, di accessibilità, di disponibilità e di interoperabilità per la gestione della piattaforma nonché il Processo di accreditamento e di fruizione del catalogo API con i limiti e le condizioni di accesso volti ad assicurare il corretto trattamento dei dati personali ai sensi della normativa vigente”.
Più in particolare, le Linee Guida individuano:
- i processi di accreditamento, identificazione e autorizzazione assicurati dalla Infrastruttura interoperabilità PDND;
- le modalità di sottoscrizione e conservazione degli accordi di interoperabilità tra i soggetti interessati, pubblici e privati;
- le modalità con cui i soggetti interessati danno seguito alle reciproche transazioni per il tramite dell’Infrastruttura interoperabilità PDND in attuazione degli accordi di interoperabilità sottoscritti;
- le modalità di raccolta e conservazione delle informazioni relative agli accessi e alle transazioni effettuate per il tramite dell’Infrastruttura interoperabilità PDND.
Riferimenti e sigle¶
Note di lettura del documento¶
Conformemente alle norme ISO/IEC Directives, Part 3 per la stesura dei documenti tecnici le presenti Linee Guida utilizzano le parole chiave «DEVE», «DEVONO», «NON DEVE», «NON DEVONO», «DOVREBBE», «NON DOVREBBE», «PUÒ» e «OPZIONALE», la cui interpretazione è descritta di seguito.
- DEVE o DEVONO, indicano un requisito obbligatorio per rispettare le Linee Guida;
- NON DEVE o NON DEVONO, indicano un assoluto divieto delle specifiche;
- DOVREBBE o NON DOVREBBE, indicano che le implicazioni devono essere comprese e attentamente pesate prima di scegliere approcci alternativi;
- PUÒ o POSSONO o l’aggettivo OPZIONALE, indica che il lettore può scegliere di applicare o meno senza alcun tipo di implicazione o restrizione la specifica.
Struttura¶
Considerata la velocità dell’innovazione, le Linee Guida devono garantire un adattamento costante ai cambiamenti imposti dall’incessante rivoluzione digitale. Di qui la scelta di allegare alle presenti Linee guida alcuni documenti i cui contenuti potranno essere adeguati più agevolmente all’evoluzione tecnologica. Tale processo di costante adeguamento degli allegati è realizzato in coerenza con il quadro normativo in materia di digitalizzazione e, nello specifico, ai sensi dell’articolo 14-bis, comma 2, lettera a) del CAD, che assegna ad AgID la funzione di “emanazione di Linee guida contenenti regole, standard e guide tecniche, nonché di indirizzo, vigilanza e controllo sull’attuazione e sul rispetto delle norme di cui al presente Codice, anche attraverso l’adozione di atti amministrativi generali, in materia di agenda digitale, digitalizzazione della pubblica amministrazione, sicurezza informatica, interoperabilità e cooperazione applicativa tra sistemi informatici pubblici e quelli dell’Unione europea”.
Le presenti Linee Guida includono i seguenti allegati:
- Allegato 1: Processo di accreditamento e principali aspetti della lettera di adesione alla Infrastruttura interoperabilità PDND
- Allegato 2: Pubblicazione e fruizione delle API
- Allegato 3: Standard e dettagli tecnici utilizzati per la fruizione dei Voucher di autorizzazione
- Allegato 4: Schema di Accordo di Interoperabilità.
Riferimenti Normativi¶
Sono riportati di seguito gli atti normativi di riferimento delle presenti Linee Guida.
[D.Lgs. 82/2005] | decreto legislativo 7 marzo 2005, n. 82 recante «Codice dell’Amministrazione Digitale»; NOTA – Il D. Lgs. 82/2010 è noto anche con l’abbreviazione «CAD». |
[D.L. 135/2018] | Decreto legge 14 dicembre 2018, n. 135 recante “Disposizioni urgenti in materia di sostegno e semplificazione per le imprese e per la pubblica amministrazione”, convertito in Legge, con modificazioni, dall’art. 1, comma 1 della Legge 11 febbraio 2019, n. 12. |
[GDPR] | Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio del 27 aprile 2016 2016/679 relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (regolamento generale sulla protezione dei dati). |
[eIDAS] | Regolamento (UE) 910/2014 del Parlamento europeo e del Consiglio, del 23 luglio 2014 , in materia di identificazione elettronica e servizi fiduciari per le transazioni elettroniche nel mercato interno e che abroga la direttiva 1999/93/CE. |
[Codice privacy] | Decreto legislativo 30 giugno 2003, n. 196 e s.m.i. recante “Codice in materia di protezione dei dati personali”. |
Linee guida di primario riferimento¶
Di seguito sono elencate le linee guida emesse dall’AgID che verranno espressamente richiamate nelle presenti Linee Guida.
[LG INTEROPERABILITÀ TECNICA] | Linee Guida sull’interoperabilità tecnica delle Pubbliche Amministrazioni. |
[LG SICUREZZA] | Linee Guida Tecnologie e standard per assicurare la sicurezza dell’interoperabilità tramite API dei sistemi informatici. |
Termini e definizioni¶
[AgID] | Agenzia per l’Italia Digitale. |
[PDND] | Piattaforma Digitali Nazionale Dati di cui all’articolo 50-ter del CAD. |
[Infrastruttura interoperabilità PDND] | L’infrastruttura tecnologica di cui al comma 2 dell’articolo 50-ter del CAD, volta a favorire l’interoperabilità dei sistemi informativi e delle basi di dati. |
[CAD] | Codice Amministrazione Digitale, D.lgs. 7 marzo 2005, n. 82. |
[MoDI] | Modello di Interoperabilità della PA definito dalle Linee Guida emanate in materia da AgID ai sensi dell’articolo 71 del CAD. |
[QoS] | Quality of Service, utilizzato per indicare i parametri usati per caratterizzare la qualità degli e-service. |
[SLI] | Service-Level Indicator, ovvero metriche atte a misurare l’efficienza dei servizi individuati dall’erogatore. |
[SLO] | Service-Level Objective, ovvero gli obiettivi degli SLI per i servizi definiti dall’erogatore. |
[SLA] | Service Level Agreement ovvero accordi sul livello di servizio frutto della contrattazione tra Erogatore e Fruitore. |
[Gestore] | La società PagoPA S.p.A a cui è affidata la realizzazione e la gestione dell’Infrastruttura interoperabilità PDND promossa dalla Presidenza del Consiglio dei Ministri. |
Ambito di applicazione¶
Le presenti Linee Guida sono emanate ai sensi dell’articolo 71 del CAD e della Determinazione dell’Agenzia per l’Italia Digitale (di seguito AgID) n. 160 del 17 maggio 2018 recante “Regolamento per l’adozione di linee guida per l’attuazione del Codice dell’Amministrazione Digitale”.
Soggetti destinatari¶
Soggetti erogatori nella Infrastruttura interoperabilità PDND¶
Le presenti Linee Guida sono destinate ai soggetti di cui all’articolo 2, comma 2, del CAD, i quali, per il tramite della Infrastruttura interoperabilità PDND, favoriscono la conoscenza e l’utilizzo del patrimonio informativo detenuto per finalità istituzionali nonché la condivisione dei dati con i soggetti che hanno diritto di accedervi ai fini dell’attuazione dell’articolo 50 del CAD e della semplificazione degli adempimenti dei cittadini e delle imprese, in conformità alla disciplina vigente, assicurando le modalità di scambio telematico per il tramite di API così come previsto dal MoDI.
In particolare, i soggetti di cui all’articolo 2, comma 2, del CAD attuano le Linee Guida al fine di condividere i dati e le informazioni da essi detenuti, assicurando:
- l’implementazione di interfacce di programmazione delle applicazioni accessibili tramite Internet (di seguito API) conformi alle [LG INTEROPERABILITÀ TECNICA];
- la registrazione delle API, di cui al precedente punto, nel Catalogo API reso disponibile dell’Infrastruttura interoperabilità PDND.
In tale contesto, i soggetti di cui all’art. 2, comma 2, del CAD agiscono in veste di soggetti erogatori.
Soggetti fruitori nella Infrastruttura interoperabilità PDND¶
Le Linee Guida sono rivolte, altresì, ai soggetti privati che, unitamente ai citati soggetti di cui all’art. 2, comma 2, del CAD, sono abilitati a fruire della PDND al fine di accedere ai dati e alle informazioni ivi resi disponibili, previa:
- sottoscrizione degli Accordi di Interoperabilità nel Catalogo API, resi disponibili dall’Infrastruttura interoperabilità PDND.
In tale contesto, i soggetti di cui all’art. 2, comma 2 del CAD e i soggetti privati agiscono in qualità di soggetti fruitori della PDND.
Gestore della Infrastruttura interoperabilità PDND¶
Le Linee guida, infine, sono rivolte altresì a PagoPA S.p.A. che le attua in merito alla progettazione, sviluppo e gestione dell’Infrastruttura interoperabilità PDND nella sua qualità di gestore, ai sensi dell’articolo 8, commi 2 e 3 del decreto legge 14 dicembre 2018, n. 135, convertito in legge 11 febbraio 2019, n. 12.
Definizioni¶
Erogatore¶
Un soggetto che rende disponibili e-service ad altri soggetti, per la fruizione di dati in suo possesso o l’integrazione di processi.
Fruitore¶
Un soggetto che, tramite la sottoscrizione di un accordo di interoperabilità, utilizza gli e-service messi a disposizione da un Erogatore.
API¶
Un insieme di procedure/funzionalità/operazioni disponibili al programmatore, di solito raggruppate a formare un insieme di strumenti specifici per l’espletamento di un determinato compito.
e-service¶
I servizi digitali realizzati da un Erogatore, attraverso l’implementazione delle necessarie API conformi alle [LG INTEROPERABILITÀ TECNICA] e alle [LG SICUREZZA], per assicurare ai Fruitori l’accesso ai propri dati e/o l’integrazione di processi.
Pattern di interazione¶
I Pattern di interazione, individuati nelle [LG INTEROPERABILITÀ TECNICA], che indicano le modalità tecniche per implementare i modelli di scambio telematico tra Erogatori e Fruitori tramite API.
Pattern di sicurezza¶
I Pattern di sicurezza, individuati nelle [LG INTEROPERABILITÀ TECNICA] nel rispetto delle [LG SICUREZZA], che delineano le modalità tecniche per assicurare che i Pattern di interazione rispettino specifiche esigenze di sicurezza (autenticazione e autorizzazione delle parti, confidenzialità delle comunicazioni, integrità dei messaggi scambiati, ecc…).
Profili di interoperabilità¶
I Profili di interoperabilità, individuati nelle [LG INTEROPERABILITÀ TECNICA], sono combinazioni di Pattern di interazione e Pattern di sicurezza per risolvere esigenze di interazione specifiche tra Erogatori e Fruitori tramite API.
Aderenti¶
I soggetti interessati in qualità di Erogatori e/o Fruitori che si sono accreditati sulla Infrastruttura interoperabilità PDND attraverso il Processo di accreditamento per usufruire delle funzionalità messe a disposizione dalla stessa infrastruttura e dare seguito alla erogazione e/o fruizione degli e-service.
Lettera di Adesione¶
Il documento sottoscritto dal rappresentante legale di un Aderente o da un professionista o da un cittadino nel caso in cui questi siano l’Aderente stesso, al fine di accreditarsi sulla Infrastruttura interoperabilità PDND e utilizzare le funzionalità messe a disposizione sulla stessa.
Utenti degli Aderenti¶
Gli utenti registrati dagli Aderenti, tramite gli strumenti messi a disposizione dall’Infrastruttura interoperabilità PDND, e da questi delegati all’uso e alla gestione delle funzionalità rese disponibili dalla stessa infrastruttura.
Le funzionalità rese disponibili dall’Infrastruttura interoperabilità PDND agli Utenti degli Aderenti e i ruoli che questi possono ricoprire sono riportati nell’Allegato 2.
Attributi degli Aderenti¶
Per Attributo si intende una caratteristica posseduta da un Aderente.
Sono individuate tre tipologie di Attributo:
- Attributi Certificati, ossia le caratteristiche possedute dall’Aderente stesso e definite sulla base delle informazioni contenute nelle banche dati di interesse nazionale e/o detenute da altre fonti autorevoli;
- Attributi Dichiarati, ossia le caratteristiche il cui possesso è stato dichiarato dall’Aderente stesso sotto la propria esclusiva responsabilità;
- Attributi Verificati, ossia le caratteristiche il cui possesso è stato indicato dall’Aderente stesso e verificato da almeno un altro Aderente, nella veste di Erogatore, in sede di stipula di un Accordo di Interoperabilità.
L’Infrastruttura interoperabilità PDND DEVE associare a ciascun Aderente gli Attributi da questo posseduti e DEVE assicurare la gestione delle tipologie di Attributi degli Aderenti.
Per quanto concerne gli Attributi Verificati di un Aderente, gli Erogatori POSSONO accettare la verifica effettuata precedentemente da un altro Erogatore.
Registro degli Attributi¶
Per Registro degli Attributi si intende la componente della Infrastruttura interoperabilità PDND in cui sono raccolti gli Attributi degli Aderenti.
L’Infrastruttura interoperabilità PDND DEVE assicurare la gestione del Registro degli Attributi.
Requisiti di Fruizione¶
I Requisiti di Fruizione, associati da ogni Erogatore a ciascun e-service pubblicato sul Catalogo API, indicano gli Attributi degli Aderenti che un Fruitore deve possedere per poter fruire dell’e-service.
Gli Erogatori utilizzano gli Attributi degli Aderenti presenti nel Registro degli Attributi per definire i Requisiti di Fruizione degli e-service.
Catalogo API¶
Il Catalogo API è la componente unica e centralizzata prevista dalle [LG INTEROPERABILITÀ TECNICA] che assicura agli Erogatori la registrazione e la pubblicazione dei propri e-service e ai Fruitori la consultazione degli e-service pubblicati.
L’Infrastruttura interoperabilità PDND integra il Catalogo API.
Il Catalogo API permette la conservazione e il recupero degli Accordi di Interoperabilità stipulati tra gli Aderenti.
Accordo di Interoperabilità¶
Gli Accordi di Interoperabilità sono stipulati tra Erogatori e Fruitori e disciplinano le modalità - rispettivamente - di erogazione e di fruizione di un e-service. Gli Accordi di Interoperabilità possono disciplinare anche gli eventuali SLA condivisi tra Erogatori e Fruitori relativamente alla erogazione e fruizione di un determinato e-service.
Gli Erogatori e i Fruitori registrano nel Catalogo API gli Accordi di Interoperabilità tra essi stipulati.
Service Level Agreements¶
Gli SLA POSSONO essere concordati tra Erogatore e Fruitore in sede di stipula di un Accordo di Interoperabilità per un determinato e-service al fine di stabilire la QoS. Gli SLA, che dovranno essere nel tempo coerenti con gli SLA dichiarati dal Gestore per l’operatività dell’Infrastruttura interoperabilità PDND, sono applicati, misurati e gestiti da Erogatore e Fruitore senza alcun coinvolgimento della Infrastruttura interoperabilità PDND e le eventuali controversie sulla loro applicazione sono risolte fra questi ultimi senza che l’Infrastruttura interoperabilità PDND svolga alcun ruolo.
Il Catalogo API, quale componente dell’Infrastruttura interoperabilità PDND, permette agli Erogatori di definire per i propri e-service gli SLI e gli SLO per la stipula degli SLA con i Fruitori.
Voucher¶
Un Voucher è la rappresentazione digitale degli elementi utili ad applicare i Requisiti di Fruizione richiesti per l’accesso ad ogni e-service pubblicato da un Erogatore.
L’Infrastruttura interoperabilità PDND, previa autenticazione del Fruitore, rilascia un Voucher in relazione ad ogni richiesta di fruizione di un e-service per cui è stato in precedenza stipulato un Accordo di Interoperabilità tra Fruitore ed Erogatore, registrato sulla stessa infrastruttura.
Il Fruitore presenta all’Erogatore il Voucher rilasciato dall’Infrastruttura interoperabilità PDND e quest’ultimo lo utilizza per verificare il soddisfacimento dei Requisiti di Fruizione per l’accesso all’e-service associato allo specifico Accordo di Interoperabilità.
Capofila¶
I Capofila sono pubbliche amministrazioni di cui all’articolo 2, comma 2, lettera a) del CAD, Aderenti all’Infrastruttura interoperabilità PDND, che sono delegate da altra pubblica amministrazione Aderente a utilizzare per suo conto le funzionalità dell’infrastruttura medesima per la registrazione e modifica degli e-service sul Catalogo API.
Una pubblica amministrazione Aderente PUÒ candidarsi ad assumere il ruolo di Capofila registrando tale volontà sull’Infrastruttura interoperabilità PDND.
Le pubbliche amministrazioni Aderenti POSSONO delegare una o più Capofila tra quelle che si sono candidate a tal fine sulla Infrastruttura interoperabilità PDND.
La delega alla Capofila ha effetto al momento dell’accettazione di quest’ultima e determina la possibilità, per i suoi Utenti degli Aderenti, di operare sulla Infrastruttura interoperabilità PDND per conto dell’Aderente delegante.
La delega da parte di un Aderente a un Capofila non include i poteri di sottoscrizione, con ruolo di fruitore, degli Accordi di Interoperabilità per conto dell’Aderente delegante.
Template e-service¶
L’Infrastruttura interoperabilità PDND favorisce i processi di co-design individuati nella Governance della Trasformazione del Piano Triennale per l’informatica nella Pubblica Amministrazione tramite il meccanismo dei Template.
Per Template e-service si intende la definizione di un modello dei descrittori di un e-service in cui restano liberi alcuni elementi operativi necessari alla reale operatività dell’e-service. In questa maniera il Template e-service resta un modello astratto a cui gli aderenti devono attenersi durante il processo di implementazione.
Il Template e-service descrive quindi come un e-service DEVE erogare il servizio non entrando nel merito di come verrà implementato né indicando le tecnologie adottate per l’implementazione delle logiche di business.
Solo dopo il processo di implementazione del Template e-service si avranno una o più istanze di un e-service reale pronto alla pubblicazione sul Catalogo API.
Il co-design coinvolge:
- API Co-design Manager: è un Aderente, che all’interno del gruppo di
Pubbliche Amministrazioni interessate al co-design di un e-service,
disegna e registra il Template e-service sull’Infrastruttura interoperabilità
PDND provvedendo a:
- dichiarare, nel rispetto del MoDI, il Template e-service delle API che implementa l’e-service;
- definire quali informazioni sono necessarie per implementare il Template e renderlo operativo, in questa maniera vengono definiti i margini di libertà entro i quali può agire chi vuole implementare l’e-service.
- Implementatore: è un Aderente che decide di implementare l’e-service
descritto da un Template e-service e provvede a:
- compilare il Template e-service definito dal API Co-design manager nel rispetto dei margini di libertà previsti;
- prendersi carico dell’implementazione della logiche di business per istanziare l’e-service.
L’Infrastruttura interoperabilità PDND permette la ricerca e l’identificazione del riferimento del Template e-service registrato dall’API Co-design manager a tutte le Aderenti.
L’Infrastruttura interoperabilità PDND promuove e comunica la pubblicazione di nuove versioni di Template e-service e supporta la pubblicazione sul Catalogo API delle istanza implementate dagli Aderenti.
Accreditamento degli Aderenti¶
Chiunque può richiedere l’accreditamento sull’Infrastruttura interoperabilità PDND mediante il Processo di accreditamento, che prevede sommariamente i seguenti passaggi:
- identificazione, tramite una delle modalità previste dall’articolo
64 del CAD, del:
- soggetto Aderente, qualora si tratti di persona fisica;
- del rappresentante legale o di un suo delegato, qualora l’Aderente sia una persona giuridica;
2. qualificazione del soggetto Aderente come pubblica amministrazione, gestore di pubblico servizio o società a controllo pubblico - ai sensi dell’articolo 2, comma 2 del CAD - oppure come soggetto privato;
3. invio, da parte della Infrastruttura interoperabilità PDND al domicilio digitale dell’Aderente, della comunicazione recante le informazioni concernenti alla richiesta di accreditamento e il codice di controllo necessario ad abilitare la prosecuzione di tale processo;
4. sottoscrizione con firma elettronica ai sensi del Regolamento eIDAS della Lettera di Adesione da parte dell’Aderente e relativo caricamento sulla Infrastruttura interoperabilità PDND;
5. sottoscrizione della Lettera di Adesione da parte del Gestore e relativa disponibilità sull’Infrastruttura Interoperabilità PDND.
La conclusione del Processo di accreditamento determina:
- nei confronti dei soggetti di cui all’articolo 2, comma 2 del CAD l’abilitazione all’utilizzo delle funzionalità previste per i ruoli di Erogatore e di Fruitore;
- nei confronti dei soggetti privati l’abilitazione all’utilizzo delle sole funzionalità previste per il ruolo di Fruitore;
- l’abilitazione del legale rappresentante dell’Aderente o del suo delegato, in qualità di Utente dell’Aderente, ad utilizzare per conto dell’Aderente le funzionalità rese disponibili dall’Infrastruttura interoperabilità PDND.
Il Processo di accreditamento è dettagliatamente disciplinato nell’Allegato 1.
Gestione degli Attributi degli Aderenti¶
L’Infrastruttura interoperabilità PDND registra gli Attributi degli Aderenti associati ad ogni singolo Aderente.
L’Infrastruttura interoperabilità PDND assicura la gestione delle seguenti tipologie di Attributi degli Aderenti:
- Certificati: associati agli Aderenti in maniera automatica dalla Infrastruttura interoperabilità PDND a partire dalle informazioni contenute nelle banche dati di interesse nazionale, in prima istanza l’Indice dei domicili digitali delle pubbliche amministrazioni e dei gestori di pubblici servizi (IPA) di cui all’articolo 6-ter del CAD, l’Indice nazionale delle imprese e dei professionisti (INI-PEC) di cui all’articolo 6-bis del CAD e l’Indice nazionale dei domicili digitali delle persone fisiche, dei professionisti e degli altri enti di diritto privato, non tenuti all’iscrizione in albi, elenchi o registri professionali o nel registro delle imprese (INAD) di cui all’articolo 6-quater del CAD, nonchè le ulteriori basi di dati di cui all’art. 60 del CAD o altre eventuali fonti autoritative. Questa tipologia di attributi è immediatamente spendibile ai fini dell’autorizzazione all’accesso agli e-service in quanto certificata da una fonte autoritativa.
- Dichiarati: i Fruitori dichiarano di possedere sotto la loro responsabilità, gli attributi richiesti al fine di soddisfare i Requisiti di Fruizione degli e-service per cui richiedono la stipula di un Accordo di Interoperabilità. L’Infrastruttura interoperabilità PDND registra gli attributi Dichiarati per singolo Aderente. Questa tipologia di attributi è immediatamente spendibile ai fini dell’autorizzazione all’accesso agli e-service in quanto la loro veridicità è garantita dal Fruitore sotto la sua esclusiva responsabilità.
- Verificati: i Fruitori dichiarano gli attributi posseduti al fine di soddisfare i Requisiti di Fruizione degli e-service per cui richiedono la stipula di un Accordo di Interoperabilità. L’Infrastruttura interoperabilità PDND registra gli attributi Dichiarati per singolo Aderente in relazione allo specifico Accordo di Interoperabilità e , a differenza degli attributi Dichiarati, a valle del riscontro positivo da parte dell’Erogatore di uno degli e-service richiesti dal Fruitore che prevedano lo stesso Attributo. L’Infrastruttura interoperabilità PDND assicura la memorizzazione del momento temporale della registrazione degli Attributi degli Aderenti.
In merito agli Attributi Verificati si precisa che:
- Un Fruitore NON DOVREBBE chiedere la verifica di un attributo Verificato che sia stato precedentemente rifiutato da un Erogatore.
- Un Erogatore PUÒ definire il periodo temporale di validità di un attributo Verificato ai fini della fruizione dei propri e-service, scaduto il quale l’attributo dovrà essere verificato nuovamente. Alla scadenza del periodo di validità individuato dall’Erogatore, l’attributo resta valido salvo il caso di un esplicito riscontro negativo della verifica fornito anche solo da un Erogatore.
- Un Erogatore PUÒ ritenere valida la verifica degli attributi realizzata da altri Erogatori in sede di stipula di un Accordo di Interoperabilità per la fruizione dei propri e-service.
- Nel caso in cui l’esito della verifica effettuata da un Erogatore relativamente ad un attributo di un Fruitore contrasti con quanto in precedenza constatato da un altro Erogatore per lo stesso Fruitore, l’Infrastruttura interoperabilità PDND comunica la circostanza agli Erogatori interessati invitandoli a dirimere l’ambiguità e a segnalare l’eventuale volontà di sospendere gli Accordi di Interoperabilità per i quali l’attributo risulta abilitante ai fini dell’accesso ai relativi e-service.
L’Infrastruttura interoperabilità PDND DEVE inserire nel Registro degli Attributi:
- gli attributi certificabili presenti nelle basi dati di interesse nazionale, o in altre fonti autorevoli, ove integrate con la Infrastruttura interoperabilità PDND;
- gli attributi proposti dagli Erogatori al momento della definizione dei Requisiti di Fruizione degli e-service pubblicati sul Catalogo API.
Gli Erogatori, al momento della definizione dei Requisiti di Fruizione dei propri e-service, DEVONO verificare se nel Registro degli Attributi sono presenti gli Attributi degli Aderenti a loro necessari. Effettuata la predetta verifica, gli Erogatori DEVONO:
- in caso di riscontro positivo, utilizzare gli attributi di loro interesse eventualmente modificando la tipologia da Dichiarati a Verificati.
- in caso di riscontro negativo, proporre la definizione di un nuovo attributo specificando la relativa tipologia richiesta (Dichiarato o Verificato). Gli Erogatori, nel proporre la definizione di un nuovo attributo alla Infrastruttura interoperabilità PDND, DEVONO associare, quando possibile, all’attributo in questione riferimenti unici presenti nelle fonti autorevoli integrate sull’Infrastruttura interoperabilità PDND (ad esempio, riferimento normativo gestito dal sistema Normattiva). Ricevuta la proposta di definizione di un nuovo attributo formulata da un Erogatore, l’Infrastruttura interoperabilità PDND provvederà ad aggiungere l’attributo al Registro degli Attributi e comunicare tale circostanza all’Erogatore.
L’Infrastruttura interoperabilità PDND DEVE mettere a disposizione del soggetto competente gli strumenti necessari a supporto della ispezione periodica alla ricerca di eventuali attributi equivalenti all’interno Registro degli Attributi. Nel caso in cui il soggetto competente constati la presenza di due o più attributi equivalenti, l’Infrastruttura interoperabilità PDND DEVE agevolare la comunicazione della circostanza agli Aderenti interessati coinvolti negli Accordi di interoperabilità che includono l’utilizzo dei suddetti attributi. Gli Aderenti interessati DEVONO comunicare le loro deduzioni sugli attributi equivalenti. In caso di riscontro positivo sull’equivalenza degli attributi a seguito dell’avallo dagli Aderenti, con l’obiettivo di ridurre lo sforzo di adeguamento degli aderenti, l’Infrastruttura interoperabilità PDND DEVE permettere agli Aderenti Erogatori:
- la creazione di un nuovo e-service che, a partire dall’e-service con attributi ridondanti all’interno del Registro degli Attributi, si adegui alla normalizzazione degli attributi equivalenti;
- la migrazione degli Accordi di interoperabilità precedentemente stipulati, dagli e-service non normalizzati verso i nuovi e-service normalizzati, prevedendo un’accettazione e conferma esplicita da parte dei Fruitori coinvolti.
L’Infrastruttura interoperabilità PDND provvede a:
- aggiornare l’associazione tra gli Aderenti e gli Attributi Certificati dipendenti dalle variazioni registrate direttamente dalle basi dati di interesse nazionale o altre fonti autorevoli utilizzate;
- recepire le variazioni comunicate dalle fonti autorevoli integrate sull’Infrastruttura interoperabilità PDND (ad esempio aggiornamento del riferimento normativo ove segnalato dal sistema Normattiva), determinare se gli Attributi associati ai riferimenti unici indicati nelle variazioni ricevute sono Dichiarati o Certificati, e segnalare agli Aderenti interessati la necessità di valutare l’impatto delle variazioni sopravvenute.
Gli Aderenti DEVONO segnalare all’Infrastruttura interoperabilità PDND ogni variazione sopravvenuta di loro conoscenza in relazione agli attributi, e nello specifico:
- i Fruitori DEVONO segnalare le variazioni relativamente agli attributi dichiarati associati ad essi;
- i Fruitori DEVONO segnalare le variazioni relativamente agli attributi verificati da essi indicati;
- gli Erogatori DEVONO segnalare le variazioni relativamente agli attributi verificati relativi ad Accordi di interoperabilità dei propri e-service.
L’Infrastruttura interoperabilità PDND, ricevute le segnalazioni di cui sopra, DEVE comunicare le circostanza agli Aderenti interessati che valutano l’impatto sugli Accordi di interoperabilità di loro interesse e comunicano alla Infrastruttura interoperabilità PDND le loro decisioni in merito agli stessi (mantenimento, sospensione o terminazione).
Catalogo API nella Infrastruttura interoperabilità PDND¶
Il MoDI individua nelle [LG INTEROPERABILITÀ TECNICA] il Catalogo delle API quale componente, unica e centralizzata, che assicura alle parti coinvolte nel rapporto di erogazione e fruizione la consapevolezza sulle API disponibili e, per ognuna di esse, i livelli di servizio dichiarati.
Il Catalogo API è realizzato al fine di:
- favorire l’uso degli e-service grazie alla loro pubblicazione e la messa a disposizione della relativa documentazione tecnica;
- agevolare la gestione del ciclo di vita degli e-service;
- mitigare la creazione di interfacce ridondanti e/o con semantica sovrapposta.
Il Catalogo API permette agli Erogatori la registrazione e pubblicazione degli e-service.
La registrazione degli e-service è realizzata dagli Erogatori che DEVONO:
- assicurare l’utilizzo delle tecnologie e l’applicazione dei pattern e dei profili individuati dal MoDI, ed in particolare dalle [LG INTEROPERABILITÀ TECNICA];
- definire i Requisiti di Fruizione individuando gli attributi che devono essere posseduti dai Fruitori per accedere allo specifico e-service.
La pubblicazione degli e-service è realizzata dagli Erogatori per rendere gli stessi disponibili agli Aderenti che soddisfano i Requisiti di Fruizione definiti.
Le informazioni presenti nel Catalogo API sono nella responsabilità degli Erogatori, che DEVONO provvedere alla gestione del ciclo di vita dei propri e-service per il tramite dei propri Utenti degli Aderenti oppure delegando questo compito a uno o più Capofila.
Il Catalogo API permette ai Fruitori di consultare l’elenco degli e-service pubblicati dagli Erogatori al fine di conoscerne le modalità di accesso e i Requisiti di Fruizione, nonché verificarne l’utilità di utilizzo per il raggiungimento delle proprie finalità.
Ogni e-service pubblicato sul Catalogo API si compone delle seguenti parti:
- i descrittori dell’e-service, che definiscono le informazioni relative alla natura dell’e-service e le informazioni tecniche per usufruire dello stesso;
- di una interfaccia (idl) per usufruire dell’e-service;
- la documentazione accessoria e manualistica per l’utilizzo del e-service.
Gli Erogatori, relativamente ai singoli e-service registrati nel Catalogo API, DEVONO assicurare l’utilizzo di una delle tecnologie indicata dal MoDI e, in particolare, dalle [LG INTEROPERABILITÀ TECNICA] attraverso la definizione di interfacce.
Nella definizione dei propri e-service, gli Erogatori DEVONO prevedere un campo per l’inoltro da parte dei Fruitori del riferimento ai documenti informatici che possano provare la legittimità dello specifico trattamento dei dati personali effettuato in occasione di ogni singolo utilizzo degli e-service. In occasione di ogni singolo utilizzo degli e-service a seguito della stipula di un Accordo di Interoperabilità:
- il Fruitore DEVE assicurare il corretto popolamento del suddetto riferimento sotto la propria completa responsabilità;
- l’Erogatore NON DEVE dare seguito alla richiesta da parte del Fruitore in assenza del suddetto riferimento.
La raccolta e la memorizzazione dei riferimenti ai documenti informatici che possano provare la legittimità degli specifici trattamenti dei dati personali effettuati in occasione di ogni singolo utilizzo di un e-service non avviene sulla Infrastruttura interoperabilità PDND.
Nel caso in cui il Fruitore sia un soggetto privato, gli stessi DEVONO implementare e assicurare la disponibilità di una API per recuperare i documenti che attestano la legittimità dello specifico trattamento dei dati personali a partire dal riferimento indicato dal Fruitore nel singolo utilizzo dell’e-service.
Contestualmente all’utilizzo degli e-service:
- il Fruitore DEVE memorizzare tutti i documenti che possono provare la legittimità del trattamento, associati univocamente al suddetto riferimento, assicurandone l’autenticità e l’integrità;
- l’Erogatore DEVE memorizzare la richiesta del Fruitore e associarla univocamente al suddetto riferimento, assicurandone l’autenticità e l’integrità;
- il Fruitore e l’Erogatore DEVONO assicurare, in qualsiasi momento, l’accesso dell’interessato e degli organi di controllo alle informazioni memorizzate.
Per la pubblicazione degli e-service sul Catalogo API, gli Erogatori DEVONO assicurare la disponibilità di un’interfaccia utilizzabile dai Fruitori.
Gli Erogatori DOVREBBERO:
- metadatare gli e-service utilizzando il modello dati supportato dall’Infrastruttura interoperabilità PDND, coerentemente ai vocabolari controllati e le ontologie relative ai servizi pubblici afferenti gli eventi aziendali e della vita definiti a livello europeo e a livello italiano;
- utilizzare i vocabolari controllati e le ontologie definiti in attuazione della “strategia nazionale dati” di cui al comma 4 dell’articolo 50-ter del CAD per la metadatazione dei dati oggetto dei propri e-service nelle modalità supportate dall’Infrastruttura interoperabilità PDND.
Relativamente agli e-service pubblicati, gli Erogatori NON POSSONO modificare elementi che impattano sui Fruitori e gli Accordi di interoperabilità già stipulati.
Gli Erogatori NON POSSONO dismettere una versione di e-service in presenza di un Accordo di Interoperabilità attivo che ne consente l’utilizzo da parte di un Fruitore.
L’Allegato 2 individua le modalità che gli Erogatori DEVONO attuare per registrare, pubblicare e aggiornare le informazioni relative ai propri e-service sul Catalogo API.
L’Allegato 2 individua le modalità che i Fruitori DEVONO attuare per consultare l’elenco degli e-service pubblicati sul Catalogo API.
Gestione degli Accordi di Interoperabilità¶
Il MoDI e, in particolare, le [LG INTEROPERABILITÀ TECNICA], prevedono che gli Accordi di Interoperabilità permettano agli Erogatori e ai Fruitori di dichiarare la costituzione di una relazione di utilizzo degli e-service.
Il processo di stipula di un Accordo di Interoperabilità, realizzato esclusivamente sulla Infrastruttura interoperabilità PDND, prevede i seguenti passaggi:
- il Fruitore individua l’e-service di proprio interesse tra quelli presenti nel Catalogo API;
- al momento dell’invio della richiesta di stipula dell’Accordo di Interoperabilità per lo specifico e-service, il Fruitore DEVE dichiarare, ove non effettuato precedentemente, il possesso degli attributi Dichiarati e/o indicare gli attributi Verificati, ove indicati fra i Requisiti di Fruizione stabiliti dall’Erogatore per quel determinato e-service;
- l’Erogatore, prima di confermare la richiesta di stipula dell’Accordo di Interoperabilità per l’e-service individuato dal Fruitore, DEVE verificare il possesso da parte del Fruitore degli attributi Verificati, a meno che l’Erogatore abbia indicato, in sede di definizione dei Requisiti di Fruizione dell’e-service oggetto dell’Accordo di Interoperabilità, di accettare le verifiche realizzate da altri Erogatori e sussista tale ultima circostanza.
Lo schema di Accordo di Interoperabilità che gli Erogatori DEVONO utilizzare per disciplinare le modalità di accesso e fruizione degli e-service pubblicati sul Catalogo API è presente nell’Allegato 4.
Il procedimento di stipula di un Accordo di Interoperabilità è concluso a seguito della sua sottoscrizione con firma elettronica ai sensi del Regolamento eIDAS da parte del Fruitore e successivamente dell’Erogatore.
Analisi del rischio sulla protezione dei dati personali¶
A valle della stipula dell’Accordo di Interoperabilità per un determinato e-service, il Fruitore, per abilitare l’utilizzo dello stesso relativamente a una specifica finalità, DEVE effettuare, sotto la propria esclusiva responsabilità e tramite gli strumenti messi a disposizione dall’Infrastruttura interoperabilità PDND, l’analisi del rischio sulla protezione dei dati personali con riferimento al trattamento derivante dalla fruizione dell’e-service.
Tale analisi del rischio DEVE prevedere almeno i seguenti aspetti:
- individuazione della base giuridica del trattamento dei dati personali oggetto della fruizione dell’e-service, ai sensi dell’articolo 6 del GDPR;
- dichiarazione della finalità per cui il Fruitore intende accedere ai dati personali messi a disposizione mediante l’e-service;
- riflessione in merito all’effettivo rispetto dei principi di cui all’articolo 5 del GDPR nella fruizione dell’e-service per la specifica finalità dichiarata;
- conferma dell’avvenuta individuazione del periodo di conservazione dei dati personali ottenuti mediante la fruizione dell’e-service.
Il Fruitore DEVE effettuare l’analisi del rischio sulla protezione dei dati personali ogni volta che intende fruire di uno specifico e-service, oggetto di un Accordo di Interoperabilità già stipulato, per una nuova e differente finalità.
Trust Infrastruttura interoperabilità PDND e sistemi informatici degli Aderenti¶
Per il tramite delle funzionalità rese disponibili dall’Infrastruttura interoperabilità PDND è realizzato il trust machine-to-machine tra:
- sistemi informatici degli Aderenti e sistemi informatici della Infrastruttura interoperabilità PDND;
- sistemi informatici degli Aderenti.
Gli Aderenti DEVONO generare il materiale crittografico utilizzato nel trust.
Gli Aderenti DEVONO assicurare la riservatezza del materiale crittografico adottando opportune misure di sicurezza che preservino l’utilizzo improprio dello stesso.
Gli Aderenti DEVONO registrare e mantenere sull’Infrastruttura interoperabilità PDND il materiale crittografico pubblico utilizzato dai propri sistemi informatici che interagiranno con la Infrastruttura interoperabilità PDND e i sistemi informatici degli altri Aderenti.
L’Infrastruttura interoperabilità PDND DEVE generare il materiale crittografico utilizzato dagli Aderenti per verificare i Voucher emessi dalla stessa infrastruttura.
L’Infrastruttura interoperabilità PDND DEVE assicurare la riservatezza del materiale crittografico adottando opportune misure di sicurezza che preservino l’utilizzo improprio degli stessi.
L’Infrastruttura interoperabilità PDND DEVE rendere disponibili agli Aderenti il materiale crittografico pubblico necessario alla verifica dei Voucher emessi dalla stessa infrastruttura.
Per dare seguito alle transazioni tra Erogatore e Fruitore sulla base di un Accordo di Interoperabilità, i sistemi informatici degli stessi DEVONO realizzare i seguenti passi:
- il sistema informatico del Fruitore richiede all’Infrastruttura interoperabilità PDND l’emissione di un Voucher riconducibile all’Accordo di Interoperabilità e alla finalità entro cui le transazioni saranno realizzate, utilizzando il materiale crittografico registrato sull’Infrastruttura interoperabilità PDND;
- l’Infrastruttura interoperabilità PDND emette un Voucher, con validità temporale limitata, contenente le informazioni necessarie ad identificare il Fruitore e l’Accordo di Interoperabilità entro cui il Voucher è stato emesso, utilizzando il materiale crittografico a tal fine generato dalla stessa infrastruttura;
- il sistema informatico del Fruitore utilizza il Voucher per richiedere accesso all’e-service pubblicato sul Catalogo API dall’Erogatore relativo all’Accordo di Interoperabilità entro cui le transazioni sono realizzate;
- il sistema informatico dell’Erogatore ricevuto il Voucher, ne verifica l’emissione da parte dell’Infrastruttura interoperabilità PDND e la validità temporale e solo in caso di verifica positiva il sistema informatico dell’Erogatore applica le regole di autorizzazione associate allo specifico Accordo di interoperabilità, nella sua completa responsabilità, per abilitare l’accesso del sistema informatico del Fruitore e provvede a dare seguito alle transazioni per l’e-service richiesto.
L’Erogatore al momento della definizione dell’Accordo di Interoperabilità PUÒ prevedere tra i Requisiti di Fruizione che il sistema informatico del Fruitore sia identificato direttamente al precedente passo 4. In questo caso il Fruitore utilizza, al precedente passo 3, il materiale crittografico registrato sull’Infrastruttura interoperabilità PDND per decorare il Voucher per permettere all’Erogatore di identificarlo.
Le tecnologie utilizzate per l’implementazione dei Voucher che l’Infrastruttura interoperabilità PDND DEVE assicurare sono indicate nell’Allegato 3.
Gli Aderenti DEVONO implementare i passi indicati in precedenza per il tramite dell’Infrastruttura interoperabilità PDND nelle modalità indicate nell’Allegato 3.
Raccolta delle informazioni relative agli accessi e alle transazioni¶
L’Infrastruttura interoperabilità PDND fornisce il supporto per il tracciamento e l’osservazione delle interazioni tra Erogatori e Fruitori. L’Infrastruttura interoperabilità PDND colleziona alcune informazioni utili a misurare l’efficacia dell’interoperabilità nel tempo ma non ha lo scopo di verificare gli SLA concordati tra Erogatori e Fruitori.
In particolare, l’articolo 50-ter, comma 2, stabilisce che l’Infrastruttura interoperabilità PDND rende possibile l’interoperabilità dei sistemi informativi e delle basi di dati anche mediante “la raccolta e conservazione delle informazioni relative agli accessi e alle transazioni effettuate suo tramite”.
A tal fine, i servizi previsti includono:
- Probing: verifica nel tempo della disponibilità delle API presenti nel
relativo Catalogo dichiarate «in erogazione». L’Aderente che eroga il
servizio deve includere nella firma dell’e-service una chiamata
secondo le indicazioni presenti nella documentazione tecnica caricata
sul portale della Infrastruttura interoperabilità PDND. L’Infrastruttura
Interoperabilità PDND conserva, anche in maniera aggregata, gli esiti
delle chiamate in termini di:
- successo/fallimento;
- coordinate temporali;
- tempi di risposta.
- Auditing: registrazione delle autorizzazioni (Voucher) rilasciate dalla
Infrastruttura Interoperabilità PDND e richieste dai Fruitori.
L’Infrastruttura interoperabilità conserva per ogni evento di
autorizzazione almeno:
- le coordinate temporali del rilascio del Voucher;
- il riferimento all’Accordo di interoperabilità stipulato;
- la finalità entro cui saranno realizzate le transazioni;
- l’URL dell’API richiesta;
- eventuali parametri con cui il Fruitore decora la richiesta di autorizzazione.
Il Gestore dell’Infrastruttura interoperabilità PDND PUÒ implementare anche un servizio di Tracing, ossia un servizio di raccolta dei tracciati che descrivono l’andamento esclusivamente quantitativo delle transazioni avvenute tra ciascun Erogatore e ciascun Fruitore. Le informazioni raccolte mediante tale servizio - che non dovranno comprendere il contenuto informativo scambiato tra Erogatore e Fruitore - descriveranno il numero di transazioni intervenute tra Erogatore e Fruitore in un determinato arco di tempo. In caso di implementazione di tale servizio, il Gestore informa gli Aderenti c on il preavviso indicato nella Lettera di Adesione. In tal caso, gli Aderenti sono tenuti a depositare, con le modalità e le tempistiche che saranno indicate nella Lettera di Adesione, sulla Infrastruttura interoperabilità PDND i tracciati delle transazioni a cui hanno partecipato in qualità sia di Erogatore sia di Fruitore.
Le informazioni depositate dagli Aderenti sull’Infrastruttura interoperabilità PDND DEVONO essere aggregate in base ai seguenti criteri:
- coordinate temporali con la granularità che sarà definita;
- Aderenti coinvolti nella transazione e loro ruolo;
- e-service oggetto della transazione (endpoint);
- esito della chiamata/risposta.
Ulteriori criteri di aggregazione delle informazioni depositate dagli Aderenti sull’Infrastruttura interoperabilità PDND POSSONO essere definiti dal Gestore.
L’obiettivo della Infrastruttura interoperabilità PDND resta ancorato alla realizzazione di un punto unico di raccolta di queste informazioni, non essendo tenuta a svolgere un compito di riconciliazione dei tracciati di una stessa transazione e provenienti da Aderenti diversi.
Livelli di servizio della Infrastruttura interoperabilità PDND¶
Il rapporto tra l’Infrastruttura interoperabilità PDND e gli Aderenti è regolato dai livelli di qualità, oggetto della Lettera di Adesione, attesi nell’erogazione dei:
- servizi offerti agli Aderenti per la gestione degli e-service, Accordi di interoperabilità e Voucher resi della Infrastruttura interoperabilità PDND;
- servizi di supporto agli Utenti degli Aderenti da parte della Infrastruttura interoperabilità PDND.
In quanto segue si riportano gli indicatori di qualità utilizzati dalla Infrastruttura interoperabilità PDND e gli Aderenti per definire i livelli di qualità dei servizi che l’Infrastruttura interoperabilità PDND garantisce agli Aderenti, oggetto della Lettera di Adesione.
Indicatori dei servizi/API realizzati¶
Tempo di risposta delle richieste su percentile¶
Il tempo che intercorre tra una request e la relativa response, è indice dell’efficienza di un servizio/API reso disponibile dall’Infrastruttura interoperabilità PDND. Nel dettaglio il tempo di risposta è calcolato, in esercizio, come il tempo intercorso tra il momento di ricezione della request e il momento di inoltro della relativa response. Le latenze determinate dal canale di comunicazione del servizio/API non sono oggetto del presente indicatore.
Il presente indicatore è determinato dalla media di un percentile fissato delle request pervenute nell’unità di tempo, dove il percentile e l’unità di tempo per la determinazione dell’indicatore sono individuate nella Lettera di adesione sottoscritta dall’Infrastruttura interoperabilità PDND e dagli Aderenti per singolo servizio/API, ad esempio tempo medio dell’85% delle richieste pervenute in 10 minuti.
La fonte per la determinazione dei tempi di ricezione delle request e il momento di inoltre delle relativa response è rappresentato dai log file tenuti dall’Infrastruttura interoperabilità PDND.
Numero di richieste per unità di tempo¶
Il numero di richieste soddisfatte da un servizio/API reso disponibile dall’Infrastruttura interoperabilità PDND è indice della capacità di carico gestibile dalla stessa.
Il presente indicatore è determinato dal numero di request soddisfate, cioè a cui il servizio/API è riuscito a produrre response, nell’unità di tempo. L’unità di tempo per la determinazione dell’indicatore è individuata nella Lettera di adesione sottoscritta dall’Infrastruttura interoperabilità PDND e dagli Aderenti per singolo servizio/API, ad esempio numero di request soddisfatte in 10 minuti.
La fonte per la determinazione del numero di request soddisfatte è rappresentato dai log file tenuti dall’Infrastruttura interoperabilità PDND.
Numero di richieste con risposta di errore per unità di tempo¶
Il numero di richieste con risposta di errore di un servizio/API reso disponibile dall’Infrastruttura interoperabilità PDND è indice inverso della efficacia della stessa.
Il presente indicato è determinato del numero di request con error response nell’unità di tempo, escludendo gli errori imputabili agli Aderenti (ad esempio errata formattazione della richiesta o la irraggiungibilità dei servizi degli Aderenti). L’unità di tempo per la determinazione dell’indicatore è individuata nella Lettera di adesione sottoscritta dall’Infrastruttura interoperabilità PDND e dagli Aderenti per singolo servizio/API, ad esempio numero di request con error response in 10 minuti. Si evidenzia che tale indicatore è inversamente proporzionale all’efficacia del servizio/API.
La fonte per la determinazione del numero di request con error response è rappresentato dai log file tenuti dalla Infrastruttura interoperabilità PDND.
Indicatori dei servizi di supporto¶
Tempestività di ripristino dell’operatività¶
Il presente indicatore si applica a non conformità funzionali e non funzionali rilevate dagli Aderenti ed è calcolato come la differenza in ore tra il momento dell’avvio del processo di risoluzione del malfunzionamento e il termine della risoluzione delle stesso da parte della Infrastruttura interoperabilità PDND.
La fonte per la determinazione dell’indicatore è rappresentato dal momento temporale delle comunicazione di merito realizzate tra l’Infrastruttura interoperabilità PDND e gli Aderenti (presa in carico del ticket da parte del Gestore).
Tempestività di risposta a segnalazioni di anomalie¶
Il presente indicatore si applica a non conformità funzionali e non funzionali evidenziate dagli Aderenti. L’indicatore è calcolato come la differenza in ore tra il momento della segnalazione e la presa in carico della stessa da parte della Infrastruttura interoperabilità PDND.
La fonte per la determinazione dell’indicatore è rappresentato dal momento temporale delle comunicazione di merito realizzate tra l’Infrastruttura interoperabilità PDND e gli Aderenti.
Disposizioni in materia di protezione dei dati personali¶
Ruolo dei soggetti coinvolti e trattamenti previsti¶
Ai sensi dell’articolo 50-ter, comma 6 del CAD, “L’accesso ai dati attraverso la Piattaforma Digitale Nazionale Dati non modifica la disciplina relativa alla titolarità del trattamento, ferme restando le specifiche responsabilità ai sensi dell’articolo 28 del Regolamento (UE) 2016/679 del Parlamento Europeo e del Consiglio del 27 aprile 2016 in capo al soggetto gestore della Piattaforma nonché le responsabilità dei soggetti accreditati che trattano i dati in qualità di titolari autonomi del trattamento”.
Premesso che la fruizione degli e-service non determina, sull’Infrastruttura interoperabilità PDND, alcun trattamento dei dati personali oggetto della trasmissione da Erogatore a Fruitore, ogni Aderente resta autonomo titolare del trattamento dei dati personali che rende disponibili o di cui fruisce nell’interazione con altro Aderente per mezzo dell’Infrastruttura interoperabilità PDND.
Resta fermo che, qualora un Aderente agisca in qualità di Capofila, questi svolge il ruolo di responsabile del trattamento ai sensi dell’articolo 4, paragrafo 1, numero 8) del GDPR per conto degli Aderenti che lo hanno nominato Capofila e che DEVONO, pertanto, formalizzare preventivamente il suo ruolo ai sensi dell’articolo 28 del GDPR. Il Gestore PUÒ implementare una funzionalità volta alla stipula dell’atto giuridico concernente la nomina dei Capofila quali responsabili del trattamento.
Il Gestore agisce come titolare del trattamento per le attività necessarie all’implementazione e alla gestione dell’Infrastruttura interoperabilità PDND.
Le attività di trattamento dei dati personali svolte dal Gestore a mezzo della Infrastruttura interoperabilità PDND sono le seguenti:
- accreditamento degli Aderenti e dei loro Utenti degli Aderenti e/o delegati;
- gestione delle attività connesse alla fruizione dell’e-service e comunicazioni con gli Aderenti necessarie alla corretta gestione della Infrastruttura interoperabilità PDND;
- attività di Auditing di cui al precedente capitolo 11;
- attività di Tracing di cui al precedente capitolo 10;
- attività di anonimizzazione e/o aggregazione sulla totalità dei dati acquisiti per finalità di analisi, studio e ricerca scientifica, sviluppo e per l’assolvimento di compiti istituzionali.
In ognuna di tali attività, il Gestore DEVE assicurare la protezione dei dati personali trattati, nel rispetto della normativa nazionale e unionale.
Atteso che sull’Infrastruttura interoperabilità PDND le uniche attività che comportano il trattamento di dati personali sono poste in atto dal Gestore, nei seguenti paragrafi sono individuate specifiche disposizioni in merito alla protezione dei dati personali rivolte al Gestore nell’implementazione e nella gestione dell’Infrastruttura interoperabilità PDND, oltre ad alcune indicazioni rivolte agli Erogatori, seppur relative ad attività esterne all’Infrastruttura interoperabilità PDND.
Resta in ogni caso fermo che qualsiasi Aderente, sia in qualità di Erogatore sia di Fruitore, nella predisposizione dei propri sistemi informatici per l’utilizzo della PDND e per l’erogazione e la fruizione delle API, DEVE operare in conformità alla normativa unionale e nazionale vigente in tema di:
- protezione dei dati personali, fra cui i provvedimenti del Garante per la protezione dei dati personali in materia di misure di sicurezza e modalità di scambio dei dati;
- continuità di servizio.
Necessità e proporzionalità del trattamento¶
Minimizzazione¶
Il Gestore DEVE ridurre il trattamento ai soli dati personali strettamente necessari per il perseguimento delle finalità poste alla base delle singole attività di trattamento e, conseguentemente, essere in grado di comprovare, nel rispetto del principio di responsabilizzazione, che i dati personali siano pertinenti, necessari e non eccessivi rispetto alla finalità perseguita.
A tal fine il Gestore DEVE effettuare una ricognizione dei dati personali il cui trattamento risulta necessario e individuare le categorie dei dati personali e degli interessati coinvolti, la finalità per cui sono trattati i dati e la base giuridica del loro trattamento.
Limitazione dei tempi di conservazione¶
Il Gestore, al fine di garantire il rispetto del principio di limitazione della conservazione e per ridurre l’impatto dei rischi gravanti sui diritti e le libertà degli interessati, NON DEVE conservare i dati personali per più tempo di quanto necessario e, in particolare:
- con riferimento alle Lettere di Adesione: per non più di 10 anni decorrenti dalla cessazione del rapporto contrattuale, a fini probatori;
- con riferimento agli Accordi di Interoperabilità: per non più di 10 anni decorrenti dalla cessazione del rapporto contrattuale, a fini probatori;
- con riferimento alle registrazioni degli e-service: per non più 10 anni decorrenti dalla cancellazione dell’API dell’e-service dal Catalogo API, a fini probatori;
- con riferimento agli Attributi degli Aderenti: per non più 10 anni decorrenti dalla cancellazione dell’attributo, a fini probatori;
- con riferimento alle attività di tracciamento dei log di sistema: per non più di 6 mesi decorrenti dalla registrazione del log;
- con riferimento alle risultanze dell’Auditing: per non più di 10 anni decorrenti dalla memorizzazione, a fini probatori;
- con riferimento alle risultanze del Tracing: per non più di 1 anno decorrente dalla memorizzazione.
Il Gestore DEVE:
- implementare misure tecniche e/o organizzative che consentano di rilevare la scadenza del periodo di conservazione;
- implementare misure tecniche e/o organizzative che consentano la cancellazione dei dati personali alla scadenza del periodo di conservazione e assicurarsi che il metodo scelto per l’eliminazione sia appropriato rispetto ai rischi legati ai diritti e alle libertà dei soggetti interessati;
- eliminare i dati personali quando il periodo di conservazione definito nella relativa procedura scade.
Misure di responsabilizzazione¶
Il Gestore DEVE predisporre una valutazione di impatto sulla protezione dei dati personali ai sensi dell’articolo 35 del GDPR e presentarla al Garante per la protezione dei dati personali ai sensi dell’art. 2-quinquiesdecies del Codice Privacy.
Tale valutazione d’impatto è messa a disposizione di tutti i soggetti Aderenti.
Qualora il trattamento di dati personali scaturente dalla predisposizione dell’e-service non sia già stato effettuato in differente modalità al di fuori dell’Infrastruttura interoperabilità PDND, altresì l’Erogatore DEVE effettuare la valutazione d’impatto sulla protezione dei dati personali ai sensi dell’articolo 35 del GDPR e annotare il relativo trattamento all’interno del proprio Registro delle attività di trattamento ai sensi dell’art. 30 del GDPR.
Trasparenza e rispetto dell’esercizio dei diritti degli utenti¶
Per quanto concerne i trattamenti la cui titolarità è individuata in capo al Gestore, questi DEVE rendere, mediante l’Infrastruttura interoperabilità PDND, un’apposita informativa ai sensi degli articoli 12, 13 e 14 del GDPR.
Ai fini della fruizione degli e-service, gli Aderenti, in sede di Accordo di interoperabilità, DEVONO darsi reciprocamente atto di aver preso visione delle rispettive informative sul trattamento dei dati personali.
Il Gestore DEVE adottare misure organizzative adeguate a garantire l’esercizio dei diritti degli interessati.
Responsabili del trattamento e trasferimenti di dati personali¶
Nell’erogazione dei servizi e delle funzionalità previste dall’Infrastruttura interoperabilità PDND, il Gestore PUÒ fare ricorso a soggetti terzi, opportunamente nominati responsabili del trattamento secondo le modalità stabilite all’articolo 28 del GDPR.
In tal caso, il Gestore DEVE privilegiare fornitori situati sul territorio nazionale e dell’Unione Europea. Laddove non sia possibile, il Gestore PUÒ ricorrere a responsabili situati in Paesi terzi, che offrano garanzie sufficienti a mettere in atto misure tecniche e organizzative adeguate alla sicurezza dei trattamenti e alla tutela dell’interessato, ponendo in tal caso una particolare attenzione all’adozione di misure tecniche e organizzative adeguate a impedire tracciamenti avulsi dalle finalità del trattamento e a evitare che terzi non autorizzati possano accedere ai dati personali, tenuto conto - ai sensi dell’articolo 32 del GDPR - dello stato dell’arte e dei costi di attuazione, nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento, come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche.
In ogni caso, il Gestore DEVE istruire i responsabili del trattamento sulla necessità di conservare i dati personali all’interno dell’Unione Europea.
Il Gestore DEVE, in ogni caso, rispettare le misure previste dal Capo V del GDPR.
Sicurezza del trattamento¶
Ai sensi del Considerando 83 e dell’articolo 32 del GDPR e nel rispetto del principio di responsabilizzazione, il Gestore DEVE implementare ogni misura tecnica e organizzativa adeguata a garantire un livello di sicurezza adeguato al rischio.
Tali misure di sicurezza comprendono almeno:
- la cifratura “in transit” e “data at rest” e l’anonimizzazione dei dati personali;
- la capacità di assicurare su base permanente la riservatezza, l’integrità, la disponibilità e la resilienza dei sistemi e dei servizi di trattamento;
- la capacità di ripristinare tempestivamente la disponibilità e l’accesso dei dati personali in caso di incidente fisico o tecnico;
- prevedere all’interno dei processi condivisi un momento dedicato a verificare e valutare regolarmente l’efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento.
Di seguito si evidenziano le “best practices” in tema di sicurezza del trattamento dei dati personali con riferimento al contesto oggetto delle presenti Linee guida.
Cifratura dei dati personali¶
Il Gestore DEVE trattare i dati implementando misure in grado di rendere incomprensibili i dati personali a chiunque non sia autorizzato ad accedervi:
determinando le componenti critiche su cui applicare misure di crittografia (“at rest”, es: dischi rigidi, file, ecc.; “in transit”, es: trasferimento da/verso un database, canali di comunicazione) in base a:
- forma/posizione in cui sono memorizzati/resi disponibili i dati personali;
- rischi individuati;
- prestazioni richieste;
scegliendo il tipo di crittografia (simmetrica o asimmetrica) in base al contesto e ai rischi individuati;
adottando soluzioni di crittografia basate su algoritmi pubblici notoriamente forti;
definendo ulteriori misure per garantire la disponibilità, l’integrità e la riservatezza delle informazioni.
Anonimizzazione dei dati personali¶
Laddove possibile, il Gestore DEVE eliminare le caratteristiche che identificano i dati personali. In particolare DEVE:
- determinare ciò che deve essere anonimo in base al contesto, alla forma in cui vengono memorizzati i dati personali (compresi i campi del database o estratti dai testi) e ai rischi individuati;
- anonimizzare permanentemente i dati che richiedono tale criterio di protezione in base alla forma dei dati (inclusi database e record testuali) e ai rischi individuati;
- se i dati non possono essere anonimizzati in modo permanente, scegliere strumenti (inclusi la cancellazione parziale, la cancellazione, la ricerca di hashing e l’indice) che rispondano innanzitutto alle esigenze funzionali.
ALLEGATO 1: Processo di accreditamento e principali aspetti della Lettera di Adesione alla Infrastruttura interoperabilità PDND¶
Introduzione¶
Il presente allegato individua il Processo di accreditamento all’Infrastruttura interoperabilità PDND e individua i contenuti principali della Lettera di Adesione che gli Aderenti sottoscrivono con il Gestore.
Il Gestore definisce la documentazione tecnica per attuare quanto disposto nel presente Allegato, considerando anche le linee guida emanate ai sensi dell’articolo 71 del CAD che hanno rilevanza per la realizzazione Infrastruttura interoperabilità PDND. La documentazione tecnica definita dal Gestore e resa disponibile agli Aderenti attraverso la pubblicazione sul portale della Infrastruttura interoperabilità PDND.
Riferimenti e sigle¶
Note di lettura del documento¶
Conformemente alle norme ISO/IEC Directives, Part 3 per la stesura dei documenti tecnici le presenti Linee Guida utilizzano le parole chiave «DEVE», «DEVONO», «NON DEVE», «NON DEVONO», «DOVREBBE», «NON DOVREBBE», «PUÒ» e «OPZIONALE», la cui interpretazione è descritta di seguito.
- DEVE o DEVONO, indicano un requisito obbligatorio per rispettare le Linee Guida;
- NON DEVE o NON DEVONO, indicano un assoluto divieto delle specifiche;
- DOVREBBE o NON DOVREBBE, indicano che le implicazioni devono essere comprese e attentamente pesate prima di scegliere approcci alternativi;
- PUÒ o POSSONO o l’aggettivo OPZIONALE, indica che il lettore può scegliere di applicare o meno senza alcun tipo di implicazione o restrizione la specifica.
Processo di accreditamento alla PDND¶
Il Processo di accreditamento consiste nei passaggi individuati nelle Linee guida al capitolo 5 Accreditamento degli Aderenti.
Il soggetto Aderente - mediante il proprio rappresentante legale o un suo delegato, in caso di soggetto giuridico - accede all’Infrastruttura interoperabilità PDND e segue il Processo di accreditamento in relazione alla categoria di appartenenza, tra quelle incluse nel paragrafo 2.1. Soggetti destinatari delle Linee guida ossia, più nello specifico:
- pubblica amministrazione o gestore di servizi pubblici, ai sensi dell’articolo 2, comma 2, lettere a) e b) del CAD, iscritti nel relativo Indice di cui all’art. 6-ter del CAD;
- società a controllo pubblico, ai sensi dell’articolo 2, comma 2, lettera c) del CAD, iscritte nell’Indice nazionale dei domicili digitali delle imprese e dei professionisti, di cui all’articolo 6-bis del CAD;
- imprese e professionisti iscritti nell’Indice nazionale dei domicili digitali delle imprese e dei professionisti, di cui all’articolo 6-bis del CAD;
- persone fisiche, professionisti o enti di diritto privato iscritti dell’Indice nazionale dei domicili digitali delle persone fisiche, dei professionisti e degli altri enti di diritto privato non tenuti all’iscrizione in albi, elenchi o registri professionali o nel registro delle imprese, di cui all’art. 6-quater del CAD.
Di seguito sono indicati i processi di accreditamento resi disponibili dall’Infrastruttura interoperabilità PDND per dare seguito all’accreditamento delle diverse tipologie di soggetti Aderenti.
Pubblica amministrazione o gestore di servizi pubblici¶
L’Infrastruttura interoperabilità PDND DEVE integrarsi con l’indice dei domicili digitali delle pubbliche amministrazioni e dei gestori di pubblici servizi (di seguito IPA), di cui all’articolo 6-ter del CAD quale fonte certificante:
- l’elenco delle pubbliche amministrazioni e dei gestori di pubblici servizi;
- il domicilio digitale delle pubbliche amministrazioni e dei gestori di pubblici servizi.
L’Infrastruttura interoperabilità PDND utilizza i seguenti dati presenti nell’IPA per verificare l’esistenza degli Aderenti:
- denominazione;
- codice fiscale;
- codice IPA;
- domicilio digitale;
ed eventualmente i dati di un’area organizzativa omogenea o unità organizzativa:
- denominazione;
- codice unico AOO o codice unico UO;
- domicilio digitale dell’area organizzativa omogenea o unità organizzativa.
Nel caso in cui si riscontri l’assenza nell’IPA del soggetto Aderente oppure si verifichi la non correttezza del domicilio digitale registrato nell’IPA, il soggetto richiedente l’adesione DEVE provvedere all’integrazione e/o correzione dei dati registrati utilizzando le procedure previste dall’IPA.
Di seguito è descritto il Processo di accreditamento per le pubbliche amministrazioni e i gestori di pubblici servizi implementato dalla Infrastruttura interoperabilità PDND.
- Una persona fisica accede all’Infrastruttura interoperabilità PDND previa identificazione tramite una delle modalità previste dall’articolo 64 del CAD.
- La persona fisica identificata ai sensi del punto 1 fornisce la sua e-mail di contatto istituzionale per le notifiche di cortesia e seleziona una pubblica amministrazione o gestore di pubblici servizi per cui vuole avviare il Processo di Accreditamento.
- La persona fisica identificata ai sensi del punto 1 compila i dati
anagrafici del rappresentante legale della pubblica amministrazione
o del gestore di pubblici servizi indicato al punto 2, fornendo:
- il nome e il cognome del rappresentante legale;
- il codice fiscale del rappresentante legale;
- l’e-mail di contatto istituzionale per le notifiche di cortesia del rappresentante legale.
- La persona fisica identificata ai sensi del punto 1 compila i dati
anagrafici di almeno un utente che potrà operare sull’Infrastruttura
interoperabilità PDND a valle della conclusione del Processo di accreditamento,
indicando:
- il nome e il cognome dell’utente;
- il codice fiscale dell’utente;
- l’e-mail di contatto istituzionale per le notifiche di cortesia dell’utente.
- L’Infrastruttura interoperabilità PDND recupera dall’IPA il domicilio
digitale della pubblica amministrazione o del gestore di pubblici
servizi indicato al punto 2 e invia a tale ente una comunicazione
con cui lo informa dell’intervenuta richiesta di avvio del Processo
di accreditamento, indicando:
- gli estremi del soggetto richiedente (persona fisica autenticata al punto 1);
- gli estremi del rappresentante legale indicato;
- gli estremi del/degli utente/i;
- la Lettera di Adesione da sottoporre alla firma digitale del rappresentante legale;
- il riferimento per recuperare il codice di controllo necessario per dare conferma delle informazioni comunicate e abilitare il soggetto richiedente - di cui al punto 1 - a proseguire il Processo di accreditamento.
- La pubblica amministrazione o il gestore di pubblici servizi indicato
al punto 2 verifica il contenuto della comunicazione ricevuta e, in
caso di riscontro positivo:
- sottopone la Lettera di Adesione alla firma del proprio rappresentante legale;
- recupera il codice di controllo e lo consegna alla persona fisica che ha avviato il Processo di accreditamento al punto 1.
- La persona fisica che ha avviato il Processo di accreditamento al punto 1 accede alla Infrastruttura interoperabilità PDND previa identificazione tramite una delle modalità previste dall’articolo 64 del CAD, presenta il codice di controllo ricevuto dalla pubblica amministrazione o dal gestore di pubblici servizi indicato al punto 2 ed effettua l’upload della Lettera di Adesione firmata digitalmente dal rappresentante legale.
- Il Gestore dell’Infrastruttura interoperabilità PDND sottoscrive la Lettera di Adesione rendendola disponibile per il download.
La positiva conclusione del Processo di accreditamento determina che:
- la pubblica amministrazione o il gestore di pubblici servizi indicato al punto 2 diviene un Aderente dell’Infrastruttura interoperabilità PDND e può svolgere il ruolo di Erogatore e/o Fruitore di e-service;
- la persona fisica identificata al punto 1, il rappresentante legale e lo/gli utente/i divengono Utenti dell’Aderente, abilitati ad operare sull’Infrastruttura interoperabilità PDND per conto della pubblica amministrazione o del gestore di pubblici servizi indicato al punto 2.
L’Infrastruttura interoperabilità PDND DEVE assicurare alle persone fisiche le funzionalità di gestione del Processo di accreditamento tramite interfacce web.
Società a controllo pubblico¶
L’Infrastruttura interoperabilità PDND DEVE integrarsi con l’indice nazionale dei domicili digitali delle imprese e dei professionisti (di seguito INI-PEC), di cui all’articolo 6-bis del CAD quale fonte certificante:
- l’elenco delle imprese;
- il domicilio digitale delle imprese.
L’Infrastruttura interoperabilità PDND utilizza i seguenti dati presenti nell’INI-PEC per verificare l’esistenza degli Aderenti:
- la ragione sociale;
- partita iva/codice fiscale;
- domicilio digitale.
Nel caso in cui si riscontri l’assenza nell’INI-PEC del soggetto richiedente l’adesione oppure, sebbene presente, tale soggetto verifichi la non correttezza del domicilio digitale registrato nell’INI-PEC, il soggetto richiedente l’adesione DEVE provvedere all’integrazione e/o correzione dei dati registrati utilizzando le procedure previste dall’INI-PEC.
Di seguito è descritto il Processo di accreditamento delle società a controllo pubblico implementato dalla Infrastruttura interoperabilità PDND.
Una persona fisica accede alla Infrastruttura interoperabilità PDND previa identificazione tramite una delle modalità previste dall’articolo 64, comma 2-quater, del CAD.
2. La persona fisica identificata ai sensi del punto 1 fornisce la sua e-mail di contatto istituzionale per le notifiche di cortesia ed individua la società a controllo pubblico per cui vuole avviare il Procedimento di adesione, indicandone:
- la ragione sociale;
- la partita iva/codice fiscale;
ed effettua l’upload della documentazione necessaria a comprovare il controllo pubblico della società.
La persona fisica identificata ai sensi del punto 1 compila i dati anagrafici del rappresentante legale della società a controllo pubblico indicata al punto 2, fornendo:
- il nome e il cognome del rappresentante legale;
- il codice fiscale del rappresentante legale;
- l’e-mail di contatto per le notifiche di cortesia.
La persona fisica identificata ai sensi del punto 1 compila i dati anagrafici di almeno un utente che potrà operare sull’Infrastruttura interoperabilità PDND a valle della conclusione del Processo di accreditamento, indicando:
- il nome e il cognome dell’utente;
- il codice fiscale dell’utente;
- l’e-mail di contatto istituzionale per le notifiche di cortesia dell’utente.
L’Infrastruttura interoperabilità PDND provvede a verificare il possesso della qualità di società a controllo pubblico in capo alla società di cui al punto 2 e, in caso di esito positivo, provvede a informare tale società, mediante una comunicazione al suo domicilio digitale acquisito dall’INI-PEC, della richiesta di avvio del Processo di accreditamento, indicando:
- gli estremi della persona fisica identificata al punto 1;
- gli estremi del rappresentante legale indicato;
- gli estremi del/degli utente/i;
- la Lettera di Adesione da sottoporre alla firma digitale del rappresentante legale;
- il riferimento necessario al recupero del codice di controllo per confermare le informazioni comunicate dalla persona identificata al punto 1 e abilitare tale persona a proseguire il Processo di accreditamento.
La società a controllo pubblico indicata al punto 2 verifica il contenuto della comunicazione ricevuta e, in caso di riscontro positivo:
- sottopone la Lettera di Adesione alla firma del proprio rappresentante legale;
- recupera il codice di controllo e lo consegna alla persona fisica che ha avviato il Processo di accreditamento al punto 1.
La persona fisica che ha avviato il Processo di accreditamento al punto 1 accede alla Infrastruttura interoperabilità PDND previa identificazione tramite una delle modalità previste dall’articolo 64 del CAD, presenta il codice di controllo ricevuto dalla società a controllo pubblico indicata al punto 2 ed effettua l’upload della Lettera di Adesione firmata digitalmente dal rappresentante legale.
Il Gestore dell’Infrastruttura interoperabilità PDND sottoscrive la Lettera di Adesione rendendola disponibile per il download.
La positiva conclusione del Processo di accreditamento determina che:
- la società a controllo pubblico indicata al punto 2 diviene un Aderente all’Infrastruttura interoperabilità PDND e può svolgere il ruolo di Erogatore e/o Fruitore di e-service;
- la persona fisica identificata al punto 1, il rappresentante legale e lo/gli utente/i del rappresentante legale divengono Utenti dell’Aderente abilitati a operare sull’Infrastruttura interoperabilità PDND per conto della società a controllo pubblico indicata al punto 2.
L’Infrastruttura interoperabilità PDND DEVE assicurare alle persone fisiche le funzionalità di gestione del Processo di accreditamento tramite interfacce web.
Imprese e professionisti di cui all’articolo 6-bis del CAD¶
L’Infrastruttura interoperabilità PDND DEVE integrarsi con l’indice nazionale dei domicili digitali delle imprese e dei professionisti (di seguito INI-PEC), di cui all’articolo 6-bis del CAD quale fonte certificante:
- l’elenco delle imprese e dei professionisti;
- il domicilio digitale delle imprese e dei professionisti.
L’Infrastruttura interoperabilità PDND utilizza i seguenti dati presenti nell’INI-PEC per verificare l’esistenza degli Aderenti:
- la ragione sociale;
- partita iva/codice fiscale;
- domicilio digitale;
e, per i soli professionisti, altresì:
- professione.
Nel caso in cui si riscontri l’assenza nell’INI-PEC del soggetto richiedente l’adesione oppure, sebbene presente, tale soggetto verifichi la non correttezza del domicilio digitale registrato nell’INI-PEC, il soggetto richiedente l’adesione DEVE provvedere all’integrazione e/o correzione dei dati registrati utilizzando le procedure previste dall’INI-PEC.
Di seguito è descritto il Processo di accreditamento delle imprese e dei professionisti presenti in INI-PEC implementato dalla Infrastruttura interoperabilità PDND.
- Una persona fisica accede alla Infrastruttura interoperabilità PDND previa identificazione tramite una delle modalità previste dall’articolo 64 del CAD.
- La persona fisica identificata ai sensi del punto 1 fornisce la sua
e-mail di contatto istituzionale per le notifiche di cortesia ed individua
una impresa o un professionista per cui vuole avviare il Processo di
accreditamento indicando:
- la ragione sociale in caso di impresa;
- il nome, il cognome, il codice fiscale e l’email di contatto lavorativo in caso di professionista;
- la partita iva dell’impresa o del professionista.
- La persona fisica identificata al punto 1, nel caso in cui al precedente
punto 2 abbia indicato un’impresa, compila i dati anagrafici del
rappresentante legale, indicando:
- il nome e il cognome del rappresentante legale;
- il codice fiscale del rappresentante legale;
- l’e-mail di contatto lavorativo per le notifiche di cortesia.
- L’Infrastruttura interoperabilità PDND acquisisce dall’INI-PEC il
domicilio digitale dell’impresa o del professionista e invia a tale
indirizzo una comunicazione con cui informa della richiesta di avvio
del Processo di accreditamento. In tale comunicazione sono indicati:
- gli estremi della persona fisica identificata al punto 1;
- gli estremi del rappresentante legale nel caso di impresa;
- gli estremi del professionista in caso di professionista;
- la Lettera di Adesione da sottoporre alla firma digitale del rappresentante legale dell’impresa o del professionista;
- il riferimento necessario al recupero del codice di controllo per confermare le informazioni comunicate dalla persona identificata al punto 1 e abilitare tale persona a proseguire il Processo di accreditamento.
- L’impresa o il professionista indicato al punto 2 verifica il contenuto
della comunicazione ricevuta presso il proprio domicilio digitale e,
in caso di riscontro positivo:
- sottopone tale Lettera di Adesione alla firma del legale rappresentante in caso di impresa o firma la Lettera di Adesione in caso di professionista;
- recupera il codice di controllo e lo consegna alla persona fisica che ha avviato il Processo di accreditamento al punto 1.
- La persona fisica che ha avviato il Processo di accreditamento al punto 1 accede alla Infrastruttura interoperabilità PDND previa identificazione tramite una delle modalità previste dall’articolo 64, comma 2-quater, del CAD, presenta il codice di controllo ed effettua l’upload della Lettera di Adesione firmata digitalmente dal rappresentante legale o dal professionista.
- Il Gestore dell’Infrastruttura interoperabilità PDND sottoscrive la Lettera di Adesione rendendola disponibile per il download.
La positiva conclusione del Processo di accreditamento determina che:
- l’impresa o il professionista indicato al punto 2 diviene un Aderente all’Infrastruttura interoperabilità PDND e può svolgere il ruolo di Fruitore di e-service;
- la persona fisica identificata al punto 1, il rappresentante legale dell’impresa o il professionista divengono Utenti dell’Aderente abilitati ad operare sull’Infrastruttura interoperabilità PDND per conto dell’impresa o del professionista indicati al punto 2.
L’Infrastruttura interoperabilità PDND DEVE assicurare alle persone fisiche le funzionalità di gestione del Processo di accreditamento tramite interfacce web.
Professionisti ed enti di diritto privato di cui all’articolo 6-quater del CAD¶
L’Infrastruttura interoperabilità PDND DEVE integrarsi con l’indice nazionale dei domicili digitali delle persone fisiche, dei professionisti e degli altri enti di diritto privato, non tenuti all’iscrizione in albi, elenchi o registri professionali o nel registro delle imprese (di seguito INAD), di cui all’articolo 6-quater del CAD quale fonte certificante:
- l’elenco degli enti di diritto privato e dei professionisti non tenuti all’iscrizione in albi, elenchi o registri professionali o nel registro delle imprese;
- il domicilio digitale di tali soggetti.
L’Infrastruttura interoperabilità PDND utilizza i seguenti dati presenti nell’INAD per verificare l’esistenza degli Aderenti:
- nome e cognome del professionista oppure denominazione dell’ente di diritto privato;
- codice fiscale;
- domicilio digitale;
e, per i solo professionisti, altresì:
- professione.
Nel caso in cui si riscontri l’assenza nell’INAD del soggetto richiedente l’adesione oppure, sebbene presente, tale soggetto verifichi la non correttezza del domicilio digitale registrato nell’INAD, il soggetto richiedente l’adesione DEVE provvedere all’integrazione e/o correzione dei dati registrati utilizzando le procedure previste dall’INAD.
Di seguito è descritto il Processo di accreditamento dei professionisti e degli enti di diritto privato presenti in INAD implementato dalla Infrastruttura interoperabilità PDND.
- Una persona fisica accede alla Infrastruttura interoperabilità PDND previa identificazione tramite una delle modalità previste dall’articolo 64 del CAD.
- La persona fisica identificata ai sensi del punto 1 fornisce la sua
e-mail di contatto istituzionale per le notifiche di cortesia e seleziona
l’ente di diritto privato o il professionista per cui vuole avviare
il Processo di accreditamento, indicando:
- denominazione in caso di ente di diritto privato;
- nome, cognome, codice fiscale ed e-mail di contatto lavorativo per le notifiche di cortesia in caso di professionista;
- partita iva o codice fiscale dell’ente di diritto privato o del professionista.
- La persona fisica identificata al punto 1, nel caso in cui al precedente
punto 2 abbia indicato un ente di diritto privato, compila i dati
anagrafici del relativo rappresentante legale indicando:
- il nome e il cognome del rappresentante legale;
- il codice fiscale del rappresentante legale;
- l’e-mail di contatto lavorativo per le notifiche di cortesia.
- L’Infrastruttura interoperabilità PDND acquisisce dall’INAD il domicilio
digitale dell’ente di diritto privato o del professionista e invia
a tale indirizzo una comunicazione con cui informa della richiesta
di avvio del Processo di accreditamento. In tale comunicazione sono
indicati:
- gli estremi della persona fisica identificata al punto 1;
- gli estremi del rappresentante legale nel caso di ente di diritto privato;
- gli estremi del professionista in caso di professionista;
- la Lettera di Adesione da sottoporre alla firma digitale del rappresentante legale o del professionista;
- il riferimento necessario al recupero del codice di controllo per confermare le informazioni comunicate dalla persona identificata al punto 1 e abilitare tale persona a proseguire il Processo di accreditamento.
- L’ente di diritto privato o il professionista indicato al punto 2
verifica il contenuto della comunicazione ricevuta e, in caso di
riscontro positivo:
- sottopone la Lettera di Adesione alla firma del proprio rappresentante legale o del professionista;
- recupera il codice di controllo e lo consegna alla persona fisica che ha avviato il Processo di accreditamento al punto 1.
- La persona fisica che ha avviato il Processo di accreditamento al punto 1 accede alla Infrastruttura interoperabilità PDND previa identificazione tramite una delle modalità previste dall’articolo 64 del CAD, presenta il codice di controllo ricevuto dall’ente di diritto privato o dal professionista indicato al punto 2 ed effettua l’upload della Lettera di Adesione firmata digitalmente dal rappresentante legale o dal professionista.
- Il Gestore dell’Infrastruttura interoperabilità PDND sottoscrive la Lettera di Adesione rendendola disponibile per il download.
La positiva conclusione del Processo di accreditamento determina che:
- l’ente di diritto privato o il professionista indicato al punto 2 diviene un Aderente all’Infrastruttura interoperabilità PDND e può svolgere il ruolo di Fruitore di e-service;
- la persona fisica identificata al punto 1, il rappresentante legale o il professionista divengono Utenti dell’Aderente abilitati a operare sull’Infrastruttura interoperabilità PDND per conto dell’ente di diritto privato o del professionista.
L’Infrastruttura interoperabilità PDND DEVE assicurare alle persone fisiche le funzionalità di gestione del Processo di accreditamento tramite interfacce web.
Persone fisiche¶
L’Infrastruttura interoperabilità PDND DEVE integrarsi con l’indice nazionale dei domicili digitali delle persone fisiche, dei professionisti e degli altri enti di diritto privato, non tenuti all’iscrizione in albi, elenchi o registri professionali o nel registro delle imprese (di seguito INAD), di cui all’articolo 6-quater del CAD quale fonte certificante:
- l’elenco delle persone fisiche che hanno eletto il proprio domicilio digitale in INAD;
- il domicilio digitale di tali persone.
L’Infrastruttura interoperabilità PDND utilizza i seguenti dati presenti nell’INAD per verificare l’esistenza degli Aderenti: - nome e cognome;
- codice fiscale;
- domicilio digitale.
Nel caso in cui si riscontri l’assenza nell’INAD del soggetto richiedente l’adesione oppure, sebbene presente, tale soggetto verifichi la non correttezza del domicilio digitale registrato nell’INAD, il soggetto richiedente l’adesione DEVE provvedere all’integrazione e/o correzione dei dati registrati utilizzando le procedure previste dall’INAD.
Di seguito è descritto il Processo di accreditamento delle persone fisiche implementato dalla Infrastruttura interoperabilità PDND.
- Una persona fisica accede all’Infrastruttura interoperabilità PDND previa identificazione tramite una delle modalità previste dall’articolo 64 del CAD, segnala di voler operare per conto proprio e fornisce la sua e-mail di contatto istituzionale per le notifiche di cortesia.
- L’Infrastruttura interoperabilità PDND recupera in INAD il domicilio
digitale della persona fisica di cui al punto 1 e invia al tale indirizzo:
- la Lettera di Adesione che il soggetto richiedente, di cui al punto 1, dovrà sottoscrivere;
- il riferimento per recuperare il codice di controllo necessario per confermare le informazioni comunicate e proseguire nel Processo di accreditamento.
- La persona fisica di cui al punto 1 verifica il contenuto della comunicazione ricevuta presso il proprio domicilio digitale e, in caso di riscontro positivo, accede alla Infrastruttura interoperabilità PDND previa nuova identificazione tramite una delle modalità previste dall’articolo 64 del CAD per effettuare, utilizzando il codice di controllo ricevuto, l’upload della Lettera di Adesione da esso firmata digitalmente.
- Il Gestore dell’Infrastruttura interoperabilità PDND sottoscrive la Lettera di Adesione rendendola disponibile per il download.
La positiva conclusione del Processo di accreditamento determina che la persona fisica diviene un Aderente all’Infrastruttura interoperabilità PDND e può svolgere il ruolo di Fruitore di e-service.
L’Infrastruttura interoperabilità PDND DEVE assicurare alle persone fisiche le funzionalità di gestione del Processo di accreditamento tramite interfacce web.
Lettera di adesione¶
Il rapporto fra ciascun Aderente e il Gestore della Infrastruttura Interoperabilità PDND è regolato mediante la Lettera di Adesione.
La Lettera di Adesione è il documento trasmesso dalla Infrastruttura Interoperabilità PDND al soggetto interessato ad aderire all’infrastruttura stessa e che DEVE essere firmato digitalmente da quest’ultimo e dal Gestore durante il Processo di accreditamento senza alterarne il contenuto e la forma.
La Lettera di Adesione DEVE prevedere almeno i seguenti aspetti:
- anagrafica dell’Aderente e del Gestore;
- servizi e funzionalità della Infrastruttura Interoperabilità PDND che il Gestore mette a disposizione dell’Aderente, comprensivi di SLA che saranno garantiti solo al di fuori di periodi e/o attività di sperimentazione, manutenzione e/o interruzione;
- modalità di adesione e fruizione della Infrastruttura interoperabilità PDND da parte dell’Aderente;
- dichiarazione dell’Aderente di presa visione delle Linee Guida, anche per conto dei propri utenti;
- informativa sul trattamento dei dati personali dell’Aderente da parte del Gestore
La Lettera di Adesione è sottoscritta con firma elettronica ai sensi del Regolamento eIDAS e, qualora l’Aderente sia una pubblica amministrazione, costituisce accordo ai ai sensi dell’articolo 15 della legge 7 agosto 1990, n. 241 e s.m.i.
ALLEGATO 2: Pubblicazione e fruizione delle API¶
Introduzione¶
Il presente allegato individua le funzionalità rese disponibili dall’Infrastruttura interoperabilità PDND agli Aderenti e, nel contempo, riporta i ruoli degli Utenti degli Aderenti gestiti dalla stessa infrastruttura.
Il Gestore definisce la documentazione tecnica per attuare quanto disposto nel presente Allegato, considerando anche le linee guida emanate ai sensi dell’articolo 71 del CAD che hanno rilevanza per la realizzazione Infrastruttura interoperabilità PDND. La documentazione tecnica definita dal Gestore e resa disponibile agli Aderenti attraverso la pubblicazione sul portale della Infrastruttura interoperabilità PDND.
Riferimenti e sigle¶
Note di lettura del documento¶
Conformemente alle norme ISO/IEC Directives, Part 3 per la stesura dei documenti tecnici le presenti Linee Guida utilizzano le parole chiave «DEVE», «DEVONO», «NON DEVE», «NON DEVONO», «DOVREBBE», «NON DOVREBBE», «PUÒ» e «OPZIONALE», la cui interpretazione è descritta di seguito.
- DEVE o DEVONO, indicano un requisito obbligatorio per rispettare le Linee Guida;
- NON DEVE o NON DEVONO, indicano un assoluto divieto delle specifiche;
- DOVREBBE o NON DOVREBBE, indicano che le implicazioni devono essere comprese e attentamente pesate prima di scegliere approcci alternativi;
- PUÒ o POSSONO o l’aggettivo OPZIONALE, indica che il lettore può scegliere di applicare o meno senza alcun tipo di implicazione o restrizione la specifica.
Linee guida di primario riferimento¶
Di seguito sono elencate le linee guida emesse dall’AgID che verranno espressamente richiamate nelle presenti Linee Guida.
[LG INTEROPERABILITÀ TECNICA] | Linee Guida sull’interoperabilità tecnica delle Pubbliche Amministrazioni. |
[LG SICUREZZA] | Linee Guida Tecnologie e standard per assicurare la sicurezza dell’interoperabilità tramite API dei sistemi informatici |
Ciclo di vita degli e-service¶
Nel MoDI si individuano gli e-service come i servizi digitali realizzati da un Erogatore, attraverso l’implementazione delle necessarie API conformi alle [LG INTEROPERABILITÀ TECNICA] e alle [LG SICUREZZA], per assicurare l’accesso ai propri dati e/o l’integrazione dei propri processi ai Fruitori.
Di seguito sono individuate le funzionalità che l’Infrastruttura interoperabilità PDND DEVE rendere disponibili agli Aderenti per la gestione del ciclo di vita degli e-service.
Gestione dei descrittori degli e-service¶
Per descrittori degli e-service si intende l’insieme di dati registrati per un determinato e-service e il cui insieme fornisce le informazioni sulle caratteristiche e il funzionamento del e-service stesso.
I descrittori degli e-service sono definiti dagli Erogatori attraverso la descrizione della natura dei propri e-service.
Gli e-service di un Erogatore sono resi disponibili ai Fruitori attraverso la pubblicazione sul Catalogo API dello specifico descrittore di e-service.
Un Erogatore DEVE definire per ogni e-service una delle tecnologie previste nel MoDI (quali REST, SOAP, …).
Un Erogatore PUÒ deprecare la pubblicazione di un descrittore di e-service per esprimere la volontà di non accettare nuovi Fruitori per il relativo e-service.
Un Erogatore PUÒ pubblicare una nuova versione di un descrittore di e-service previa deprecazione della versione precedente. La nuova versione di un descrittore di e-service DEVE assicurare l’invarianza dei requisiti di fruizione e del modello di interoperabilità applicato per essa. Alla pubblicazione di una nuova versione di un descrittore di e-service, l’Infrastruttura interoperabilità PDND DEVE comunicare tale circostanza ai Fruitori che hanno stipulato un Accordo di interoperabilità per l’e-service.
Un Erogatore NON PUÒ avere più di un descrittore di e-service in stato “attivo” per un dato e-service.
Gli Erogatori DEVONO prevedere un campo per l’inoltro, da parte dei Fruitori, del riferimento ai documenti informatici che possano provare la liceità dello specifico trattamento dei dati personali (ci si riferisce ad esempio al consendo dell’interessato nei casi di applicazione dell’articolo 6 paragrafo 1 lettera del GDPR).
Nel caso in cui l’Erogatore preveda soggetti privati tra i Fruitori di un proprio e-service, lo stesso Erogatore DEVE definire per l’e-service una API che i Fruitori privati DEVONO implementare per assicurare il recupero dei documenti che attestano la liceità dello specifico trattamento dei dati personali.
L’Infrastruttura interoperabilità PDND DEVE archiviare una versione di un descrittore di e-service deprecata dall’Erogatore nel caso in cui non siano stati sottoscritti Accordi di Interoperabilità per quello specifico descrittore di e-service.
Ciclo di vita¶
Un descrittore di un e-service è legato allo stesso e-service durante tutto il suo ciclo di vita.
Gli stati di un descrittore di e-service sono:
- “bozza”, l’Erogatore provvede a popolare gli attributi del descrittore di e-service;
- “attivo”, l’Erogatore rende disponibile l’e-service agli Aderenti per la stipula di Accordi di Interoperabilità;
- “deprecato”, l’Erogatore esprime la volontà di non accettare nuovi Fruitori ma ne assicura la disponibilità per i Fruitori che hanno già stipulato un Accordo di Interoperabilità ;
- “archiviato”, le informazioni del descrittore di e-service sono conservate dall’Infrastruttura interoperabilità PDND nel caso in cui non siano stati sottoscritti Accordi di Interoperabilità relativi allo specifico descrittore di e-service.
Le azioni realizzate dall’Erogatore per variare lo stato di un descrittore di e-service sono:
- SALVA, da “bozza” a “bozza”: l’Erogatore popola i dati e i metadati del descrittore di e-service indicati in 4.1.2. Data model e registra quanto popolato per completarlo successivamente
- PUBBLICA, da “bozza” a “pubblicato”: l’Erogatore pubblica il descrittore di e-service a condizione che i dati e i metadati obbligatori siano stati popolati;
- AGGIORNA, da “pubblicato” a “pubblicato”: l’Erogatore aggiorna i dati e i metadati modificabili del descrittore di e-service;
- DEPRECA, da “pubblicato” a “deprecato”: l’Erogatore rende non più disponibile l’e-service per la stipula di Accordi di Interoperabilità;
- CANCELLA, da “bozza”: l’Erogatore cancella il descrittore di e-service quando ancora in bozza.
L’Infrastruttura interoperabilità PDND provvede a cambiare lo stato di un descrittore di e-service da “attivo” a “deprecato” quando l’Erogatore pubblica una nuova versione dello stesso descrittore.
L’Infrastruttura interoperabilità PDND effettua controlli periodici sui descrittori di e-service e provvede a cambiare lo stato dello stesso in “archiviato” di un descrittore di e-service nel caso in cui lo stato risulti “deprecato” e non sono presenti Accordi di Interoperabilità per lo specifico e-service notificando all’Erogatore il passaggio di stato.
Il successivo diagramma di stato riporta gli stati di un descrittore di e-service e per essi le relative transizioni caratterizzate dall’azione realizzata dall’Erogatore e dai vincoli per la loro esecuzione, separati da “:”. Si precisa che in assenza di azioni indicate si assume che l’Infrastruttura interoperabilità PDND esegue in automatico la transizione al presentarsi della condizione abilitante la stessa.
L’Infrastruttura interoperabilità PDND DEVE assicurare la possibilità agli Erogatori di utilizzare i dati e metadati di un descrittore di e-service registrati per definire e pubblicare una nuova versione dello stesso descrittore di e-service o un nuovo e-service.
L’Infrastruttura interoperabilità PDND DEVE assicurare le funzionalità agli Utenti degli Aderenti, tramite interfacce web, per la gestione dei descrittori di e-service che assicurano quanto descritto in precedenza.
L’Infrastruttura interoperabilità PDND DEVE assicurare le funzionalità agli Aderenti, tramite API REST, per la gestione dei descrittori di e-service che assicurano quanto descritto in precedenza.
Data model¶
Nella seguente tabella sono riportati i dati minimi del descrittori di e-service.
nome | descrizione | tipo | cardinalità | obbligatorio | modificabile |
---|---|---|---|---|---|
id eservice | identificativo univoco dell’eservice | uri | [1..1] | SI | NO |
nome | nome dell’e-service | text | [1..1] | SI | NO |
descrizione | descrizione dell’e-service | text | [0..1] | NO | SI |
versione | versione dell’e-service | number | [1..1] | SI | NO |
versione | versione dell’e-service | number | [1..1] | SI | NO |
contatti amministrativi | contatti dell’Erogatore utili ai potenziali Fruitori per avviare le interazione in merito all’e-service | CONTATTO | [1..n] | SI | SI |
tecnologia | tecnologia dell’interfaccia | (‘REST’,’SOAP’) | [1..1] | SI | NO |
id erogatore | identificativo univoco dell’erogatore | uri | [1..1] | SI | NO |
id capofila | identificativo univoco del capofila | uri | [0..1] | NO | NO |
requisiti di fruizione | requisiti di fruizione per l’accesso all’e-service | ATTRIBUTO | [0..1] | SI | NO |
modello accordo di interoperabilità | modello di accordo di interoperabilità utilizzato per l’e-service | uri | [0..1] | NO | NO |
interfaccia | interfaccia che descrive la modalità di accesso al servizio | INTERFACCIA | [1…1] | SI | NO |
interfaccia retrive | interfaccia che descrive la modalità di accesso al servizio che il Fruitore privato deve implementare per assicura all’Erogatore la possibilità di recuperari i documenti che attestano la legittimità dello specifico trattamento dei dati personali | INTERFACCIA | [0…1] | NO | NO |
data registrazione | data dell’ultima modifica dei dati dell’eservice | date | [1..1] | SI | SI |
data pubblicazione | data della pubblicazione dell’eservice | date | [0..1] | NO | NO, l’attributo è valorizzato una sola volta all’esecuzione della transazione di stato PUBBLICA dall’Infrastruttura Interoperabilità PDND |
data revoca | data della revoca dell’eservice | date | [0..1] | NO | NO, l’attributo è valorizzato una sola volta all’esecuzione della transazione di stato REVOCA dall’Infrastruttura Interoperabilità PDND |
data archiviazione | data dell’archiviazione dell’eservice | date | [0..1] | NO | NO, l’attributo è valorizzato una sola volta all’esecuzione dell’archiviazione dall’Infrastruttura Interoperabilità PDND |
I metadati minimi associati ai descrittori di e-service dagli Erogatori rispettano le indicazioni fornite dal Gestore nella documentazione tecnica da esso definita per attuare quanto disposto nel presente Allegato.
L’Infrastruttura interoperabilità PDND gestisce i dati di servizio necessari ad assicurare l’implementazione delle funzionalità per la gestione dei descrittori di e-service coerentemente quanto descritto in precedenza.
Stipula dell’accordo di interoperabilità¶
Nel MoDI si individuano gli Accordi di Interoperabilità per permettere agli Erogatori e ai Fruitori di dichiarare l’utilizzo degli e-service, comprensivo degli eventuali SLA condivisi tra essi.
Il processo di stipula di un Accordo di Interoperabilità è realizzato su richiesta di un Fruitore per il tramite dell’Infrastruttura di Interoperabilità.
Il Fruitore identifica l’e-service di proprio interesse, considerando l’ultima versione del relativo descrittore di e-service dello stesso tra quelli presenti nel Catalogo API e prende visione:
- dell’interfaccia disponibile per l’utilizzo dell’e-service;
- dei requisiti di fruizione dell’e-service;
- del modello di Accordo di Interoperabilità.
I Fruitori, che non riscontrano la disponibilità di e-service per le proprie finalità all’interno del Catalogo API, POSSONO inoltrare agli Aderenti interessati una richiesta motivata di predisposizione di nuovi e-service per il tramite dell’Infrastruttura interoperabilità PDND. Gli Aderenti destinatari di tale richiesta DEVONO valutare in autonomia l’opportunità di darle seguito e DEVONO comunicare ai Fruitori le evidenze scaturite dalla valutazione per il tramite dell’Infrastruttura interoperabilità PDND.
Il Fruitore, con riferimento agli attributi dichiarati indicati nei requisiti di fruizione dell’e-service che non risultano tra quelli ad esso già associati sull’Infrastruttura Interoperabilità PDND, DEVE appurare se le condizioni per determinare l’associazione da un Aderente sono da esso soddisfatte e, in caso di esito positivo, DEVE dichiarare sotto la propria esclusiva responsabilità l’attributo. L’Infrastruttura di Interoperabilità DEVE registrare la dichiarazione del Fruitore associando ad esso l’attributo dichiarato.
Il Fruitore, per gli attributi verificati indicati nei requisiti di fruizione dell’e-service che non risultano tra quelli ad esso già associati sull’Infrastruttura di Interoperabilità, DEVE appurare se le condizioni per determinare l’associazione da un Aderente sono da esso soddisfatte ed, in caso di esito positivo, DEVE indicare l’attributo. L’Infrastruttura di Interoperabilità DEVE registrare l’indicazione del Fruitore.
Il Fruitore PUÒ riportare nella richiesta della stipula di un Accordo di Interoperabilità gli SLA concordati con l’Erogatore.
Il Fruitore DEVE compilare il modello di Accordo di Interoperabilità indicato dall’Erogatore ed allegarlo alla richiesta della stipula di un Accordo di Interoperabilità.
Il Fruitore PUÒ richiedere la stipula di un Accordo di Interoperabilità per uno specifico e-service solo se ad esso risultano:
- associati tutti gli attributi certificati e dichiarati indicati nei requisiti di fruizione dell’e-service;
- associati o indicati tutti gli attributi verificati indicati nei requisiti di fruizione dell’e-service.
L’Infrastruttura Interoperabilità PDND registra la richiesta di stipula di un Accordo di Interoperabilità e la inoltra all’Erogatore dell’e-service oggetto dello stesso.
Ricevuta la richiesta di stipula di un Accordo di Interoperabilità, l’Erogatore DEVE:
- verificare la completezza delle informazioni del modello di Accordo di Interoperabilità compilato dal Fruitore;
- verificare che il Fruitore sia in possesso di tutti gli attributi indicati
nei requisiti di fruizione dell’e-service e, nello specifico, per quanto
riguarda gli attributi Verificati:
- verificare se sussistono le condizioni per l’associazione di un attributo Verificato indicato dal Fruitore, se precedentemente non verificato da altro Erogatore nel caso in cui lo stesso Erogatore abbia indicato di accettare tale verifica;
- verificare se sussistono le condizioni per l’associazione di un attributo verificato indicato dal Fruitore, per tutti gli attributi per cui lo stesso Erogatore abbia indicato di non accettare le verifiche effettuate da altro Erogatore;
- verificare la correttezza degli SLA riportati dal Fruitore, ove applicabili.
L’Erogatore alternativamente DEVE:
- accettare la richiesta di stipula di un Accordo di Interoperabilità;
- registrare le motivazioni che impediscono l’accettazione della richiesta di stipula di un Accordo di Interoperabilità comprese le eventuali circostanze che hanno determinato l’esito negativo delle precedenti verifiche.
L’Infrastruttura Interoperabilità PDND registra quanto indicato dall’Erogatore e, nel caso di non accettazione da parte di quest’ultimo, comunica al Fruitore le motivazioni indicate.
In caso di accettazione della richiesta di stipula di un Accordo di Interoperabilità da parte dell’Erogatore, l’Infrastruttura Interoperabilità PDND rende disponibile alle parti lo stesso per la sottoscrizione con firma elettronica ai sensi del Regolamento eIDAS.
Successivamente alla stipula di un Accordo di Interoperabilità:
- l’Erogatore PUÒ sospendere temporaneamente la disponibilità dell’e-service segnalando in anticipo al Fruitore tale circostanza nel rispetto delle condizioni eventualmente indicate negli SLA concordati con il Fruitore;
- l’Erogatore, nel caso abbia indicato per uno o più attributi Verificati periodo temporale di validità nei requisiti di fruizione dell’e-service, DEVE effettuare la verifica periodica degli stessi attributi Verificati coerentemente al periodo temporale di validità indicato e registrarne gli esiti sull’Infrastruttura di Interoperabilità;
- l’Erogatore PUÒ effettuare la verifica degli attributi Verificati relativi ai Fruitori dei propri e-service in ogni momento lo ritenga utile e registrarne gli esiti sull’Infrastruttura di Interoperabilità;
- il Fruitore DEVE registrare sull’Infrastruttura di Interoperabilità la decadenza dei propri attributi Dichiarati;
- l’Infrastruttura di Interoperabilità, nel caso al variare degli attributi del Fruitore si determini una inadempimento dei requisiti di fruizione indicati dall’Erogatore, DEVE comunicare al Fruitore e all’Erogatore la circostanza e sospendere l’Accordo di Interoperabilità sulla base delle indicazioni pervenute dagli stessi;
- l’Infrastruttura di Interoperabilità, nel caso in cui un l’Erogatore abbia indicato per un attributo Verificato di accettare la verifica di altri Erogatori e un periodo temporale di validità per uno specifico e-service, DEVE aggiornare la data di ultima verifica per tale attributo relativamente a tutti gli Accordi di Interoperabilità che afferiscono allo stesso e-service in corrispondenza della verifica effettuata da almeno un Erogatore;
- l’Infrastruttura di Interoperabilità DEVE comunicare all’approssimarsi del periodo temporale di validità di un attributo Verificato agli Erogatori interessati la circostanza;
- il Fruitore PUÒ terminare l’Accordo di Interoperabilità fatti salvi gli eventuali vincoli concordati con l’Erogatore al momento della stipula dello stesso.
Nel caso in cui l’Erogatore pubblichi una nuova versione di un descrittore di e-service relativo all’e-service oggetto di un Accordo di Interoperabilità, i Fruitori DOVREBBERO provvedere a implementare la nuova versione del descrittore di e-service e a registrare tale circostanza sull’Infrastruttura Interoperabilità PDND referenziando la nuova versione del descrittore di e-service utilizzata nel relativo Accordo di Interoperabilità.
Data model¶
Nella seguente tabella sono riportati i dati minimi dell’Accordo di interoperabilità.
nome | descrizione | tipo | cardinalità | obbligatorio | modificabile |
---|---|---|---|---|---|
id accordo di interoperabilità | identificativo univoco dell’accordo di interoperabilità | uri | [1..1] | SI | NO |
id eservice | riferimento all’e-service | uri | [1..1] | SI | NO |
versione eservice | versione dell’e-service in uso | number | [1..1] | SI | SI |
id interfaccia | riferimento all’interfaccia | uri | [1..1] | SI | NO |
id fruitore | riferimento al Fruitore | uri | [1..1] | SI | NO |
endpont retrive | endpoint dell’interfaccia implementata dal Fruitore privato per assicura all’Erogatore la possibilità di recuperari i documenti che attestano la legittimità dello specifico trattamento dei dati personali | url | [0..1] | NO | SI |
Voucher time-to-live | numero di secondi di validità del Voucher | number | [1..1] | NO | NO |
Voucher PoP | indica se il Voucher deve essere decorato dalla PoP da parte dell’Erogatore | boolean | [1..1] | SI | NO |
sla | collezione degli SLA concordati tra Erogatore e Fruitore | SLA | [0..n] | NO | SI |
ref accordo di interoperabilità | riferimento all’accordo di interoperabilità stipulato tra Erogatore e Fruitore | uri | [0..1] | NO | SI |
motivi non accettazione | motivazione che impediscono l’accettazione della stipula da parte dell’Erogatore | (data, text) | [0..n] | NO | SI |
sospensione temporanea | indica se l’e-service è temporaneamente sospeso da parte dell’Erogatore | (data start, data end) | [0..n] | NO | SI |
data registrazione | data dell’ultima modifica dei dati dell’accordo di interoperabilità | date | [1..1] | SI | SI |
data richiesta | data della richiesta di stipula dell’accordo di interoperabilità | date | [0..1] | NO | NO, l’attributo può essere valorizzato una sola volta al momento della richiesta di stipula da parte del Fruitore |
data approvazione | data di approvazione di stipula dell’accordo di interoperabilità | date | [0..1] | NO | NO, l’attributo può essere valorizzato una sola volta al momento della accettazione da parte dell’Erogatore |
data terminazione | data della richiesta di terminazione dell’accordo di interoperabilità | date | [0..1] | NO | NO, l’attributo può essere valorizzato una sola volta al momento della richiesta di stipula da parte del Fruitore |
L’Infrastruttura interoperabilità PDND gestisce i dati di servizio necessari ad assicurare l’implementazione delle funzionalità per la gestione degli accordi di interoperabilità coerentemente quanto descritto in precedenza.
Data model condivisi¶
In quanto segue sono riportati dei data model condivisi nelle differenti definizioni delle entità gestite dall’Infrastruttura Interoperabilità PDND riportate in precedenza.
INTERFACCIA¶
Rappresenta un attributo che deve essere associato ad un Erogatore ad un descrittore e-service, nella seguente tabella sono riportati i dati minimi dell’entità INTERFACCIA.
nome | descrizione | tipo | cardinalità | obbligatorio | modificabile |
---|---|---|---|---|---|
id interfaccia | identificativo univoco dell’interfaccia | uri | [1..1] | SI | NO |
idl | specifica dell’interfaccia, dipendente dalla tecnologia, nello specifico per OpenAPI per REST e WSDL per SOAP | text | [1..1] | SI | SI |
slo | collezione degli SLO dell’interfaccia | SLO | [0..n] | NO | SI |
pattern/profili | collezione dei pattern/profili del MoDI utilizzati dall’interfaccia | PATTERN/PROFILI | [1..n] | SI | NO |
documentazione | documentazione accessoria e manualistica per l’utilizzo dell’interfaccia | uri | [0..n] | NO | SI |
contatti tecnici | contatti dell’Erogatore utili ai Fruitori per ricevere dettagli tecnici sull’interfaccia | CONTATTO | [0..n] | NO | SI |
data registrazione | data dell’ultima modifica dei dati dell’interfaccia | date | [1..1] | SI | SI |
data completato | data del completamento dell’interfaccia | date | [0..1] | NO | NO, l’attributo può essere valorizzato una sola volta all’esecuzione della transazione di stato COMPLETA |
data archiviazione | data dell’archiviazione dell’eservice | date | [0..1] | NO | NO, l’attributo può essere valorizzato una sola volta all’esecuzione dell’archiviazione |
ATTRIBUTO¶
Rappresenta un attributo che deve essere associato ad un potenziale Fruitore di un e-service, nella seguente tabella sono riportati i dati minimi dell’entità ATTRIBUTO.
nome | descrizione | tipo | cardinalità | obbligatorio | modificabile |
---|---|---|---|---|---|
id attributo | identificativo univoco dell’attributo | uri | [1..1] | SI | NO |
tipo | tipo attributo | (‘certificato’, ‘dichiarato’, ‘verificato’) | [1..1] | SI | NO |
verifica obbligatoria | indica se l’erogatore si riserva di effettuare la verifica dell’attributo | boolean | [1..1] | SI | NO |
periodo validità verifica | indica il numero di giorni per cui la verifica realizzata ha effetto | number | [0..1] | NO | NO |
ultima verifica | indica la data in cui è stata effettuata l’ultima verifica | date | [0..1] | NO | SI |
“id attributo” DEVE essere popolato con i valori presenti nel registro degli Attributi degli Aderenti gestito dall’Infrastruttura interoperabilità PDND.
Il registro degli Attributi degli Aderenti gestito dall’Infrastruttura interoperabilità PDND registra per ogni attributo:
- l’identificativo univoco dell’attributo;
- la descrizione dell’attributo comprensiva delle condizioni per determinare l’associazione da un Aderente;
- la tipologia (“certificato”, “dichiarato”, “verificato”) dell’attributo;
- la fonte collegata all’attributo la cui indicazione è obbligatoria per attributi della tipologia “certificato”;
- l’eventuale riferimento specifico della fonte collegata.
CONTATTO¶
Rappresenta un contatto reso dagli Erogatori, nella seguente tabella sono riportati i dati minimi dell’entità CONTATTO.
nome | descrizione | tipo | cardinalità | obbligatorio | modificabile |
---|---|---|---|---|---|
id contact | identificativo univoco di un contatto | uri | [1..1] | SI | NO |
nome | nome della persona fisica | text | [1..1] | SI | NO |
cognome | cognome della persona fisica | text | [1..1] | SI | NO |
telefono | telefono della persona fisica | text | [1..1] | SI | SI |
email della persona fisica | text | [1..1] | SI | SI |
PATTERN/PROFILI¶
Rappresenta un pattern o un profilo definito dal MoDI, nella seguente tabella sono riportati i dati minimi dell’entità PATTERN/PROFILI.
nome | descrizione | tipo | cardinalità | obbligatorio | modificabile |
---|---|---|---|---|---|
id pattern profilo | identificativo univoco di un pattern o profilo | uri | [1..1] | SI | NO |
tipo | tipologia di pattern o profilo | (‘pattern interazione’, ‘pattern sicurezza’, ‘profilo’) | [1..1] | SI | NO |
name | nome del pattern o profilo | text | [1..1] | SI | NO |
descrizione | descrizione del pattern o profilo | text | [1..1] | SI | NO |
“id pattern profilo” DEVE essere popolato con il riferimento al pattern o profilo definito nel MoDI.
SLI¶
Riporta uno service level indicator, nella seguente tabella è riportato sono riportati i dati minimi dell’entità SLI.
nome | descrizione | tipo | cardinalità | obbligatorio | modificabile |
---|---|---|---|---|---|
id sli | identificativo univoco di uno slo | uri | [1..1] | SI | NO |
descrizione | descrizione dello sli | text | [1..1] | SI | NO |
SLO¶
Riporta uno service level objectives, nella seguente tabella sono riportati i dati minimi dell’entità SLO.
nome | descrizione | tipo | cardinalità | obbligatorio | modificabile |
---|---|---|---|---|---|
id slo | identificativo univoco di uno slo | uri | [1..1] | SI | NO |
id sli | riferimento allo sli | SLI | [1..1] | SI | NO |
descrizione | descrizione dello slo | text | [1..1] | SI | NO |
funzione | funzione di calcolo dello slo | text | [1..1] | SI | NO |
SLA¶
Riporta uno service level objectives, nella seguente tabella sono riportati i dati minimi dell’entità SLA.
nome | descrizione | tipo | cardinalità | obbligatorio | modificabile |
---|---|---|---|---|---|
id sla | identificativo univoco di uno slo | uri | [1..1] | SI | NO |
id slo | riferimento allo sli | SLI | [1..1] | SI | NO |
descrizione | descrizione dello sla | text | [1..1] | SI | NO |
funzione | funzione di calcolo dello sla | text | [1..1] | SI | NO |
Categorie degli Utenti degli Aderenti¶
L’Infrastruttura interoperabilità PDND permette agli Aderenti di dichiarare i propri utenti come Utenti degli Aderenti assegnando ad essi uno o più delle seguenti categorie, fatto salvo la fattispecie degli Aderenti nel caso di cittadino.
Operatore Amministrativo¶
Gli Utenti degli Aderenti a cui è assegnata la presente categoria possono:
- quando l’Aderente opera come Erogatore:
- confermare gli attributi Verificati indicati dagli Aderenti che chiedono la stipula di Accordi di Interoperabilità;
- rispondere alle richieste di stipula di un Accordo di Interoperabilità;
- rispondere alle richieste di definizione di un nuovo e-service inoltrate da un Aderente;
- quando l’Aderente opera come Fruitore:
- attribuirsi gli attributi Dichiarati necessari al soddisfacimento dei requisiti di fruizione degli e-service;
- indicare gli attributi Verificati necessari al soddisfacimento dei requisiti di fruizione degli e-service;
- richiedere la stipula di un Accordo di Interoperabilità;
- inoltrare la richiesta di un nuovo e-service ad un Aderente;
- registra le finalità per un Accordo di Interoperabilità stipulato;
- registra un Client Fruitore e associarlo ad un Operatore Sicurezza;
- associa un Client Fruitore alle finalità per un Accordo di Interoperabilità stipulato;
- quando l’Aderente opera come Erogatore o Fruitore:
- registra altri utenti con il ruolo di Operatore API e Operatore Sicurezza;
- gestisce la stipula di un Accordo di Interoperabilità, nello specifico richiesta di stipula come Fruitore e conferma di stipula come Erogatore;
- predispone la nomina di un nuovo Operatore Amministrativo, con gli strumenti messi a disposizione dall’Infrastruttura PDND Interoperabilità e, a valle della ricezione della comunicazione inoltrata dall’Infrastruttura PDND Interoperabilità al domicilio digitale dell’ente, la sottopone alla firma del rappresentate legale e, successivamente, deposita la stessa sulla Infrastruttura PDND Interoperabilità;
- rimuove altri utenti con il ruolo di Operatore Amministrativo o utenti con il ruolo di Operatore API e Operatore Sicurezza.
Operatore API¶
Gli Utenti degli Aderenti a cui è assegnata la presente categoria possono:
- quando l’Aderente opera come Erogatore:
- gestire il ciclo di vita degli e-service.
Operatore Sicurezza¶
Gli Utenti degli Aderenti a cui è assegnata la presente categoria possono:
- quando l’Aderente opera come Fruitore:
- registrare il materiale crittografico pubblico dei Client Fruitore a cui è associato.
- quando l’Aderente opera come Erogatore:
- registrare il materiale crittografico pubblico dei Server Erogatore a cui è associato.
ALLEGATO 3: Standard e dettagli tecnici utilizzati per la fruizione dei Voucher di autorizzazione¶
Introduzione¶
Il presente allegato individua gli standard e le tecnologie per l’emissione e fruizione dei Voucher di autorizzazione per l’utilizzo di un e-service e le modalità tecniche attuate dagli Aderenti per l’utilizzo degli stessi.
Il Gestore definisce la documentazione tecnica per attuare quanto disposto nel presente Allegato, considerando anche le linee guida emanate ai sensi dell’articolo 71 del CAD che hanno rilevanza per la realizzazione Infrastruttura interoperabilità PDND. La documentazione tecnica definita dal Gestore e resa disponibile agli Aderenti attraverso la pubblicazione sul portale della Infrastruttura interoperabilità PDND.
Riferimenti e sigle¶
Note di lettura del documento¶
Conformemente alle norme ISO/IEC Directives, Part 3 per la stesura dei documenti tecnici le presenti Linee Guida utilizzano le parole chiave «DEVE», «DEVONO», «NON DEVE», «NON DEVONO», «DOVREBBE», «NON DOVREBBE», «PUÒ» e «OPZIONALE», la cui interpretazione è descritta di seguito.
- DEVE o DEVONO, indicano un requisito obbligatorio per rispettare le Linee Guida;
- NON DEVE o NON DEVONO, indicano un assoluto divieto delle specifiche;
- DOVREBBE o NON DOVREBBE, indicano che le implicazioni devono essere comprese e attentamente pesate prima di scegliere approcci alternativi;
- PUÒ o POSSONO o l’aggettivo OPZIONALE, indica che il lettore può scegliere di applicare o meno senza alcun tipo di implicazione o restrizione la specifica.
Standard di riferimento¶
Sono riportati di seguito gli standard tecnici indispensabili per l’applicazione delle presenti Linee Guida.
[X.509] | Standard per la crittografia asimmetrica definito in RFC5280 |
[JWT] | JSON Web Token definito in RFC7519 |
[JWT-BCP] | JWT Best Current Practices definito in RFC8725 |
[JWK] | JSON Web Key (JWK) in RFC7517 |
Linee guida di primario riferimento¶
Di seguito sono elencate le linee guida emesse dall’AgID che verranno espressamente richiamate nelle presenti Linee Guida.
[LG INTEROPERABILITÀ TECNICA] | Linee Guida sull’interoperabilità tecnica delle Pubbliche Amministrazioni |
[LG SICUREZZA] | Linee Guida Tecnologie e standard per assicurare la sicurezza dell’interoperabilità tramite API dei sistemi informatici |
Trust degli Aderenti alla PDND¶
La Infrastruttura Interoperabilità PDND DEVE fornire agli Aderenti le funzionalità necessarie ad assicurare l’autenticazione e autorizzazione dei Fruitori al fine di accedere agli e-service messi a disposizione degli Erogatori.
L’identificazione degli Aderenti, assicurata dal processo di accreditamento all’Infrastruttura interoperabilità PDND, determina un insieme definito di partecipanti (“sistema chiuso”).
Si assume come prerequisito per la comunicazione tra Erogatori e Fruitori che:
- gli Erogatori DEVONO registrare sul Catalogo API gli e-service che mettono a disposizione dei Fruitori e i relativi Requisiti di fruizione che questi ultimi devono soddisfare per accedere agli e-service;
- gli Erogatori e Fruitori DEVONO stipulare sulla Infrastruttura interoperabilità PDND un Accordo di interoperabilità per gli e-service a cui il Fruitore ha intenzione di accedere;
- il Fruitore DEVE dichiare le finalità entro cui utilizzerà gli e-service oggetto degli Accordi di interoperabilità stipulati.
Il trust realizzato tra l’Infrastruttura interoperabilità PDND e gli Aderenti è fondato sul:
- materiale crittografico registrato sull’Infrastruttura interoperabilità PDND dai Fruitori;
- la certezza della fonte per la verifica dello stesso materiale crittografico realizzata dall’Infrastruttura interoperabilità PDND.
I Fruitori DEVONO registrare sulla Infrastruttura interoperabilità PDND i loro sistemi informatici (di seguito Client Fruitore) che utilizzeranno gli e-service pubblicati sul Catalogo API dagli Erogatori.
Fatta salva la necessità di registrare almeno un Client Fruitore per potere fruire degli e-service pubblicati sul Catalogo API dagli Erogatori, i Fruitori POSSONO registrare più Client Fruitore sull’ Infrastruttura interoperabilità PDND.
Per ogni Client Fruitore DEVE essere associato il materiale crittografico generato dal Fruitore stesso.
Per garantire la continuità della fruizione in caso di aggiornamento degli algoritmi (si veda RFC7696 Algorithm Agility sezione 2.3) l’Infrastruttura interoperabilità PDND DEVE permettere di associare più istanze di materiale crittografico ai Client Fruitore .
I Fruitori relativamente al materiale crittografico associato ai Client Fruitore registrati sulla Infrastruttura interoperabilità PDND DEVONO assicurare i necessari aggiornamenti in caso di compromissione del materiale crittografico.
L’Infrastruttura interoperabilità PDND DEVE assicurare l’integrità e l’immodificabilità del materiale crittografico associato ai Client Fruitore.
I Fruitori per ogni Accordo di interoperabilità stipulato per il tramite dell’Infrastruttura interoperabilità PDND e per ogni finalità registrata per lo stesso accordo DEVONO associare i Client Fruitore che accederanno agli e-service oggetto dell’accordo per dare seguito alla specifica finalità. Un Fruitore PUÒ associare uno stesso Client Fruitore a più Accordi di interoperabilità e così anche per le finalità.
L’Infrastruttura interoperabilità PDND DEVE realizzare la funzione di Registry per il materiale crittografico registrato dagli Aderenti.
La Infrastruttura interoperabilità PDND DEVE rendere disponibili agli Utenti degli aderenti le funzionalità per permettere agli:
- Operatori Amministrativi di registrare un Client Fruitore e associarlo ad un Operatore Sicurezza;
- Operatori di Sicurezza di registrare il materiale crittografico pubblico dei Client Fruitore a cui è associato.
L’Infrastruttura interoperabilità PDND DEVE tracciare le operazione realizzate dagli Utenti degli Aderenti relative alla:
- registrazione dei Client Fruitore;
- associazione del materiale crittografico ai Client Fruitore;
- registrazione dei Client Fruitore che accedono agli e-service oggetto di Accordi di interoperabilità.
L’Infrastruttura interoperabilità PDND DEVE rendere accessibile il materiale crittografico pubblico registrato dagli Aderenti. L’accesso DEVE essere garantito tramite API REST conformi alle [LG INTEROPERABILITÀ TECNICA] applicando il pattern sicurezza [ID_AUTH_CHANNEL_01] con l’utilizzo di certificati qualificati ai sensi del [eIDAS] e delle [LG SICUREZZA].
Gli Erogatori DEVONO utilizzare sui propri sistemi informatici che implementano gli e-service registrati sul Catalogo API certificati X.509, nel rispetto delle [LG SICUREZZA], per assicurare almeno l’applicazione del pattern di sicurezza [ID_AUTH_CHANNEL_01] individuato nelle [LG INTEROPERABILITÀ TECNICA]. Gli Erogatori si dotano dei suddetti certificati X.509 al di fuori della Infrastruttura interoperabilità PDND.
Sulla base della tipologia dei dati oggetto delle comunicazioni realizzate per il tramite degli e-service messi a disposizione dei Fruitori, gli Erogatori DEVONO individuare gli opportuni pattern e profili previsti nelle [LG INTEROPERABILITÀ TECNICA].
Materiale crittografico¶
I Fruitori tramite le funzionalità della Infrastruttura interoperabilità PDND associano ad ognuno dei propri Client Fruitore il materiale crittografico.
Il materiale crittografico generato nel dominio dei Fruitori DEVE rispettare quanto indicato dal Gestore nella documentazione tecnica predisposta dallo stesso per attuare quanto disposto nel presente Allegato, posto che:
- il materiale crittografico deve rispettare le “Raccomandazioni in merito agli algoritmi per XML Canonicalization, Digest and signature public key SOAP e Digest and signature public key REST” previste dalle [LG SICUREZZA];
- il materiale crittografico NON DEVE essere utilizzato con algoritmi di Message Authentication Code (MAC);
- il materiale crittografico associato ai Client Fruitore NON DEVE mai contenere chiavi private;
- la Infrastruttura interoperabilità PDND pubblica il materiale crittografico in formato [JWK] RFC7517 Sezione 5 tramite API REST conformi alle [LG INTEROPERABILITÀ TECNICA];
- la Infrastruttura interoperabilità PDND genera ed associa un identificativo univoco al materiale crittografico registrato dai Fruitori;
- i Fruitori NON POSSONO modificare l’identificativo univoco generato dalla Infrastruttura interoperabilità PDND.
La Infrastruttura interoperabilità PDND NON DEVE permettere di associare uno specifico materiale crittografico a più Client Fruitore.
La Infrastruttura interoperabilità PDND in caso di variazione del materiale crittografico di un Client Fruitore DEVE notificare la circostanza agli Erogatori degli e-service fruiti dallo stesso Client Fruitore e per cui è abilitata l’opzione “Voucher PoP”.
Protocollo di emissione dei Voucher con API REST¶
L’Infrastruttura interoperabilità PDND DEVE assicurare l’emissione dei Voucher utilizzati dai Fruitori per accedere agli e-service degli Erogatori rendendo disponibile agli stessi delle API REST conformi alle [LG INTEROPERABILITÀ TECNICA].
I profili di emissione dei Voucher sono definiti come applicazione del RFC6749, assumendo che i Voucher sono gli Access Token indicati nell’RFC, prevedendo la seguente mappatura dei ruoli:
- Resource Owner: corrisponde all’Erogatore che, tramite le funzionalità della Infrastruttura interoperabilità PDND per la definizione dei Requisiti di fruizione degli e-service, individua le policy di accesso ai propri e-service;
- Resource Server: è il sistema informatico dell’Erogatore che rende disponibile l’e-service;
- Client: corrisponde al sistema informatico (di seguito Client Fruitore) del Fruitore che, a valle della stipula di un Accordo di Interoperabilità e l’indicazione delle finalità entro cui utilizzerà lo stesso accordo, accede all’e-service erogato dal Resource Server;
- Authorization Server: corrisponde alla componente dell’Infrastruttura interoperabilità PDND che emette, nel rispetto degli Accordi di Interoperabilità stipulati dagli Aderenti, gli Access Token per autorizzare l’accesso agli e-service degli Erogatori.
I passi previsti nel flusso base indicato in RFC6749 trovano la corrispondenza indicata di seguito.
- L’Authorization request ed il rilascio dell’Authorization Grant è assicurato tramite la richiesta di stipula dell’Accordo di interoperabilità da parte del Fruitore ed alla successiva conferma di accettazione da parte dell’Erogatore. Il processo è realizzato per il tramite dell’Infrastruttura interoperabilità PDND. Tali passi non sono oggetto dei profili indicati di seguito ma sono garantiti dalle funzionalità per la stipula degli Accordi di Interoperabilità assicurate dalla Infrastruttura interoperabilità PDND;
- La Infrastruttura interoperabilità PDND DEVE erogare le funzionalità di Authorization Server implementando il Token Endpoint per permettere al Fruitore di dare seguito all’Access Token Request. L’Infrastruttura interoperabilità PDND ricevuta l’Access Token Request di un Client Fruitore autentica lo stesso e verifica la presenza e la validità dell’Accordo di Interoperabilità, le finalità indicate nella richiesta ed in caso di esito positivo rilascia l’Access Token in accordo con quanto definito nello stesso accordo (ad esempio time-to-leave del Access Token);
- Il Fruitore utilizza l’Access Token ricevuto dalla Infrastruttura interoperabilità PDND per accedere all’e-service dell’Erogatore oggetto dell’Accordo di Interoperabilità.
[REST_JWS_2021_Bearer] Profilo di emissione dei Voucher JWS Bearer¶
Il presente profilo è definito assumendo che:
- l’Access Token Request del Client Fruitore all’Infrastruttura interoperabilità PDND è basata su JSON Web Token (JWT) Profile for OAuth 2.0 (RFC7523);
- l’autenticazione del Client Fruitore da parte dell’Infrastruttura interoperabilità PDND è realizzata utilizzando il materiale crittografico registrato sulla stessa infrastruttura;
- l’Infrastruttura interoperabilità PDND emette un Bearer Access Token OAuth2 conforme all’RFC6750 veicolato tramite l’HTTP Header Authorization definito in RFC7235;
- l’Access Token emesso dall’Infrastruttura interoperabilità PDND consiste in un JWS conforme all’RFC7515 firmato dall’Infrastruttura interoperabilità PDND.
Sulla base dell’Accordo di interoperabilità stipulato dagli Aderenti la validità temporale dell’Access Token emesso dall’Infrastruttura interoperabilità PDND PUÒ essere basata su un time-to-live eventualmente definito dall’Erogatore ed entro cui lo stesso può essere utilizzato dal Client Fruitore per accedere all’e-service oggetto dello specifico accordo.
Access Token Request del Client Fruitore¶
Le informazioni contenute nell’Access Token Request del Client Fruitore DEVONO permettere alla Infrastruttura interoperabilità PDND di individuare le seguenti informazioni:
- l’indicazione del Client Fruitore per cui si richiede l’emissione dell’Access Token;
- l’indicazione dell’Accordo di interoperabilità che abilità il Client Fruitore all’accesso all’e-service dell’Erogatore;
- l’indicazione della finalità associata dal Fruitore all’Accordo di interoperabilità entro cui il Client Fruitore si impegna ad utilizzare la risposta dell’e-service dell’Erogatore.
Access Token¶
Le informazioni contenute nell’Access Token emesso dall’Infrastruttura interoperabilità PDND DEVONO permettere all’Erogatore di individuare almeno le seguenti informazioni:
- l’indicazione del Client Fruitore per cui è stato emesso l’Access Token;
- l’indicazione dell’Accordo di interoperabilità verificata dall’Infrastruttura interoperabilità PDND che abilità il Client Fruitore all’accesso all’e-service dell’Erogatore;
- l’indicazione della finalità associata dal Fruitore all’Accordo di interoperabilità verificata dall’Infrastruttura interoperabilità PDND entro cui il Client Fruitore si impegna ad utilizzare la risposta dell’e-service dell’Erogatore.
Inoltro dell’Access Token all’Erogatore¶
Il Client Fruitore implementa la request all’e-service del Erogatore nel rispetto di quanto registrato da quest’ultimo sul Catalogo API e DEVE inserire nella richiesta l’Access Token emesso dall’Infrastruttura interoperabilità PDND nell’HTTP header Authorization come indicato in RFC6750.
Il Fruitore assicura il tracciamento delle richieste effettuate con l’Access Token emesso dall’Infrastruttura interoperabilità PDND.
Verifica del Voucher da parte dell’Erogatore¶
L’Erogatore, ricevuta la richiesta del Client Fruitore, DEVE almeno verificare:
- la validità della firma dell’Access Token apposta dall’Infrastruttura interoperabilità PDND mediante il materiale crittografico generato dalla stessa infrastruttura a tal fine e le informazioni contenute nel JWT;
- la scadenza dell’Access Token ed il time-to-live, ove presente, nel rispetto di quanto stipulato nell’Accordo di interoperabilità con il Fruitore.
In caso di esito positivo delle verifiche l’Erogatore DEVE dare accesso al Client Fruitore all’e-service oggetto dell’Accordo di interoperabilità.
Nel caso di fallimento delle verifiche l’Erogatore NON DEVE dare accesso al Client Fruitore all’e-service oggetto dell’Accordo di interoperabilità.
L’Erogatore assicura il tracciamento delle richieste ricevute dai Client Fruitore con gli Access Token emessi dall’Infrastruttura interoperabilità PDND.
Le specifiche tecniche delle API REST rese disponibili dall’Infrastruttura interoperabilità PDND per permettere ai Client Fruitori di dare seguito all’Access Token Request e il dettaglio del contenuto dell’Access Token emesso dalla stessa infrastruttura sono oggetto della documentazione tecnica predisposta dal Gestore.
[REST_JWS_2021_POP] Profilo di emissione dei Voucher JWS POP¶
Considerata la possibile esigenza che in alcuni scenari sia richiesto un grado di protezione aggiuntivo nel dominio di sicurezza del Fruitore, in base al quale un Client Fruitore, necessita di una proof-of-possession del materiale crittografico utilizzato per l’Access Token Request, in modo tale che lo stesso sia l’unico a potere utilizzare il relativo Access Token emesso dall’Infrastruttura interoperabilità PDND per l’accesso ad un determinato e-service.
Il presente profilo estende il profilo REST_JWS_2021_Bearer sopra definito affinché l’Access Token emesso dall’Infrastruttura interoperabilità PDND per l’accesso ad un determinato e-service non costituisca un token di accesso al portatore, e quindi utilizzabile da qualunque parte ne entri in possesso, ma sia resa possibile la verifica da parte dell’Erogatore del Client Fruitore che ha richiesto l’emissione del token e per il quale il token è stato emesso.
Access Token Request del Client Fruitore¶
Le informazioni contenute nell’Access Token Request del Client Fruitore DEVONO permettere alla Infrastruttura interoperabilità PDND di individuare le seguenti informazioni:
- l’indicazione del Client Fruitore per cui si richiede l’emissione dell’Access Token;
- l’indicazione dell’Accordo di interoperabilità che abilità il Client Fruitore all’accesso all’e-service dell’Erogatore;
- l’indicazione della finalità associata dal Fruitore all’Accordo di interoperabilità entro cui il Client Fruitore si impegna ad utilizzare la risposta dell’e-service dell’Erogatore;
- Un proof-of-possession del materiale crittografico privato corrispondente al materiale crittografico pubblico a cui l’’Access Token richiesto deve essere collegato.
Access Token¶
Le informazioni contenute nell’Access Token emesso dall’Infrastruttura interoperabilità PDND DEVONO permettere all’Erogatore di individuare almeno le seguenti informazioni:
- l’indicazione del Client Fruitore per cui è stato emesso l’Access Token;
- l’indicazione dell’Accordo di interoperabilità verificata dall’Infrastruttura interoperabilità PDND che abilità il Client Fruitore all’accesso all’e-service dell’Erogatore;
- l’indicazione della finalità associata dal Fruitore all’Accordo di interoperabilità verificata dall’Infrastruttura interoperabilità PDND entro cui il Client Fruitore si impegna ad utilizzare la risposta dell’e-service dell’Erogatore;
- l’indicazione della proof-of-possession ricevuta nell’’Access Token Request per cui il token è emesso.
Inoltro dell’Access Token all’Erogatore¶
Il Client Fruitore implementa la request all’e-service del Erogatore nel rispetto di quanto registrato da quest’ultimo sul Catalogo API e DEVE inserire nella richiesta l’Access Token emesso dall’Infrastruttura interoperabilità PDND nell’HTTP header Authorization come indicato in RFC6750 e la relativa proof-of-possession collegata.
Il Fruitore assicura il tracciamento delle richieste effettuate con l’Access Token emesso dall’Infrastruttura interoperabilità PDND.
Verifica del Voucher da parte dell’Erogatore¶
L’Erogatore, ricevuta la richiesta del Client Fruitore, DEVE almeno verificare:
- la validità della firma dell’Access Token apposta dall’Infrastruttura interoperabilità PDND mediante il materiale crittografico generato dalla stessa infrastruttura a tal fine e le informazioni contenute nel JWT;
- la scadenza dell’Access Token ed il time-to-live, ove presente, nel rispetto di quanto stipulato nell’Accordo di interoperabilità con il Fruitore;
- la validità della proof-of-possession collegata all’Access Token.
In caso di esito positivo delle verifiche l’Erogatore DEVE dare accesso al Client Fruitore all’e-service oggetto dell’Accordo di interoperabilità.
Nel caso di fallimento delle verifiche l’Erogatore NON DEVE dare accesso al Client Fruitore all’e-service oggetto dell’Accordo di interoperabilità.
L’Erogatore assicura il tracciamento delle richieste ricevute dai Client Fruitore con gli Access Token emessi dall’Infrastruttura interoperabilità PDND.
Le specifiche tecniche delle API REST rese disponibili dall’Infrastruttura interoperabilità PDND per permettere ai Client Fruitori di dare seguito all’Access Token Request e il dettaglio del contenuto dell’Access Token emesso dalla stessa infrastruttura sono oggetto della documentazione tecnica predisposta dal Gestore.
Allegato 4 - Schema di Accordo di Interoperabilità¶
Schema di Accordo di Interoperabilità
tra
_____________ (di seguito anche solo “Erogatore”), con sede in _____________ (Provincia), Via/Piazza _____________ n. _____________ - CAP _____________ Codice Fiscale/Partita IVA _____________ indirizzo domicilio digitale (es. PEC) _____________ in persona del dott./dott.ssa _____________ con ruolo di _____________ (nella sua qualità di legale rappresentante pro tempore e/o soggetto munito dei necessari poteri alla sottoscrizione del presente accordo);
e
Se persona giuridica:
_____________ (di seguito anche solo “Fruitore”), con sede in _____________ (Provincia), Via/Piazza _____________ n. _____________ - CAP _____________ Codice Fiscale/Partita IVA _____________ indirizzo domicilio digitale (es. PEC) _____________ in persona di _____________ con ruolo di _____________ (nella sua qualità di legale rappresentante pro tempore e/o soggetto munito dei necessari poteri alla sottoscrizione del presente accordo);
Se persona fisica:
_____________ (di seguito anche solo “Fruitore”), nato a _________, il __________ residente in _____________ (Provincia), Via/Piazza _____________ n. _____________ - CAP _____________ Codice Fiscale _____________ domicilio digitale (es. PEC) _____________;
L’Erogatore e il Fruitore, di seguito singolarmente “Parte” e congiuntamente “Parti”
PREMESSO CHE
- ai sensi dell’articolo 50, comma 1, del decreto legislativo 7 marzo 2005, n. 82, recante “Codice dell’amministrazione digitale” (nel seguito anche “CAD”), “I dati delle pubbliche amministrazioni sono formati, raccolti, conservati, resi disponibili e accessibili con l’uso delle tecnologie dell’informazione e della comunicazione che ne consentano la fruizione e riutilizzazione, alle condizioni fissate dall’ordinamento, da parte delle altre pubbliche amministrazioni e dai privati; restano salvi i limiti alla conoscibilità dei dati previsti dalle leggi e dai regolamenti, le norme in materia di protezione dei dati personali ed il rispetto della normativa comunitaria in materia di riutilizzo delle informazioni del settore pubblico”;
- ai sensi dell’articolo 50, comma 2 del CAD “Qualunque dato trattato da una pubblica amministrazione, con le esclusioni di cui all’articolo 2, comma 6, salvi i casi previsti dall’articolo 24 della legge 7 agosto 1990, n. 241, e nel rispetto della normativa in materia di protezione dei dati personali, e” reso accessibile e fruibile alle altre amministrazioni quando l’utilizzazione del dato sia necessaria per lo svolgimento dei compiti istituzionali dell’amministrazione richiedente, senza oneri a carico di quest’ultima, salvo per la prestazione di elaborazioni aggiuntive”;
- ai sensi dell’articolo 50-ter, comma 1, del CAD, “La Presidenza del Consiglio dei ministri promuove la progettazione, lo sviluppo e la realizzazione di una Piattaforma Digitale Nazionale Dati (PDND) finalizzata a favorire la conoscenza e l’utilizzo del patrimonio informativo detenuto, per finalità istituzionali, dai soggetti di cui all’articolo 2, comma 2, nonché la condivisione dei dati tra i soggetti che hanno diritto ad accedervi ai fini dell’attuazione dell’articolo 50 e della semplificazione degli adempimenti amministrativi dei cittadini e delle imprese, in conformità alla disciplina vigente”;
- ai sensi dell’articolo 50-ter, comma 2, del CAD “La Piattaforma Digitale Nazionale Dati è gestita dalla Presidenza del Consiglio dei ministri ed è costituita da un’infrastruttura tecnologica che rende possibile l’interoperabilità dei sistemi informativi e delle basi di dati delle pubbliche amministrazioni e dei gestori di servizi pubblici per le finalità di cui al comma 1, mediante l’accreditamento, l’identificazione e la gestione dei livelli di autorizzazione dei soggetti abilitati ad operare sulla stessa, nonché” la raccolta e conservazione delle informazioni relative agli accessi e alle transazioni effettuate suo tramite. La condivisione di dati e informazioni avviene attraverso la messa a disposizione e l’utilizzo, da parte dei soggetti accreditati, di interfacce di programmazione delle applicazioni (API)”;
- il Fruitore intende accedere ai dati e alle informazioni detenuti dall’Erogatore tramite la Infrastruttura interoperabilità PDND secondo quanto previsto nel presente accordo di interoperabilità (di seguito “Accordo”).
Tutto ciò premesso, le Parti, come in epigrafe rappresentate STIPULANO E CONVENGONO QUANTO SEGUE
Art. 1 - Definizioni
- Ai fini del presente Accordo, si applicano le seguenti definizioni:
- Aderente: il soggetto che ha aderito alla Infrastruttura interoperabilità PDND attraverso il processo di accreditamento.
- API: un insieme di procedure, funzionalità, operazioni disponibili al programmatore e di solito raggruppate per formare un insieme di strumenti specifici per l’espletamento di un determinato compito.
- Attributo/i: le caratteristiche possedute dagli Aderenti. In base a quanto previsto nelle Linee Guida AgID, gli Attributi possono essere Certificati, Dichiarati e Verificati.
- Catalogo API: componente unica e centralizzata che assicura agli Erogatori e ai Fruitori la consapevolezza sulle API disponibili e per esse le modalità di fruizione, e sulla quale sono registrati anche gli Accordi di Interoperabilità.
- Erogatore: il soggetto che rende disponibile un E-service sulla Infrastruttura interoperabilità PDND per permettere la fruizione di dati in suo possesso o l’integrazione dei processi da esso realizzati.
- E-service: il servizio digitale realizzato e messo a disposizione dall’Erogatore, attraverso l’implementazione delle necessarie API conformi a quanto indicato nelle Linee guida AgID per assicurare l’accesso ai propri dati e/o l’integrazione dei propri processi ai Fruitori, disciplinato dal presente Accordo.
- Fruitore: il soggetto che, tramite la sottoscrizione del presente Accordo, accede e fruisce dell’E-service messo a disposizione dall’Erogatore.
- Allegato tecnico: il documento che descrive nel dettaglio caratteristiche e modalità tecniche di accesso e fruizione dell’E-service messo a disposizione dall’Erogatore.
- Infrastruttura interoperabilità PDND: l’infrastruttura tecnologica che rende possibile l’interoperabilità dei sistemi informativi e delle basi di dati dei soggetti di cui all’articolo 2, comma 2, del CAD, mediante l’accreditamento, l’identificazione e la gestione dei livelli di autorizzazione dei soggetti abilitati ad operare sulla stessa, nonché la raccolta e la conservazione delle informazioni relative agli accessi e alle transazioni effettuate per suo tramite di cui all’art. 50-ter, comma 2, del CAD.
- Lettera di Adesione: la lettera sottoscritta dall’Aderente e trasmessa a PagoPA S.p.A. - in qualità di gestore della Infrastruttura interoperabilità PDND - attraverso cui l’Aderente stesso manifesta la volontà ad accreditarsi sulla Infrastruttura.
- Linee Guida AgID: le linee guida AgID sull’infrastruttura tecnologica per l’interoperabilità dei sistemi informativi e delle basi di dati di cui all’art. 50-ter, comma 2, del CAD.
- Requisiti di Fruizione: gli Attributi stabiliti da un Erogatore, e che i Fruitori devono possedere, per accedere a un determinato E-service e poter stipulare l’Accordo di Interoperabilità necessario ai fini della fruizione dello stesso.
- Service Level Agreement (SLA): l’accordo sul livello di servizio concordato fra l’Erogatore e il Fruitore in fase di erogazione di un E-service - coerenti con gli SLA dichiarati nella Lettera di Adesione relativi all’operatività dell’Infrastruttura interoperabilità PDND - composto da metriche misurabili.
- Utente/i: ogni persona fisica che accede alla Infrastruttura interoperabilità PDND ed è autorizzata dall’Aderente ad agire per suo conto sulla Infrastruttura stessa. In base a quanto previsto nelle Linee Guida AgID, gli Utenti possono essere Operatori API, Operatori di Sicurezza, Operatori Amministrativi.
ART. 2 - Oggetto
- Il presente Accordo disciplina le modalità di accesso, da parte del Fruitore, all’E-service ____________ messo a disposizione dall’Erogatore, secondo gli SLA definiti dagli stessi al di fuori della Infrastruttura interoperabilità PDND e registrati sulla Infrastruttura stessa.
ART. 3 - Oneri economici
- Eventuali oneri economici tra le Parti sono individuati dalle stesse, al di fuori della Infrastruttura interoperabilità PDND, nel rispetto della normativa vigente.
ART. 4 - Obblighi e responsabilità delle Parti
- In capo alle Parti grava l’obbligo di operare nel pieno rispetto delle disposizioni di cui alle Linee guida AgID e al presente Accordo.
- In capo al Fruitore gravano i seguenti obblighi, essendo nella sua esclusiva responsabilità:
- richiedere la stipula del presente Accordo tramite l’Infrastruttura Interoperabilità PDND unicamente ove ad esso risultino associati o indicati tutti gli Attributi Certificati, Dichiarati e Verificati previsti nei Requisiti di fruizione stabiliti dall’Erogatore per la fruizione dell’E-service;
- effettuare l’analisi del rischio sulla protezione dei dati personali che saranno ottenuti mediante la fruizione dell’E-service, compilando tutti i campi dello strumento messo a disposizione dalla Infrastruttura interoperabilità PDND con riferimento ad ogni specifica finalità di fruizione dell’E-service stesso;
- per fruire dell’E-service per la specifica finalità dichiarata ai sensi della precedente lettera b), comunicare direttamente all’Erogatore - al di fuori dell’Infrastruttura - il riferimento ai documenti informatici che possano dimostrare la sussistenza del rapporto intercorrente tra il Fruitore e il soggetto di cui sono richiesti i dati personali e che consenta di accedere legittimamente a tutti i dati e le informazioni messi a disposizione dall’Erogatore tramite l’E-service;
- utilizzare i dati e le informazioni di cui entrerà in possesso in fase di fruizione dell’E-service solo per la/e finalità dichiarate e nei limiti di quest’ultima/e, nonché solo per il tempo strettamente necessario allo svolgimento delle attività per cui ne è stata richiesta la fruizione;
- su richiesta dell’Erogatore, aderire alle eventuali successive versioni dell’E-service predisposte e rilasciate sul Catalogo API, entro __________ giorni dal ricevimento di specifica comunicazione da parte dell’Erogatore, e provvedere conseguentemente a dismettere la versione precedente dell’E-service;
- individuare all’interno della propria organizzazione e accreditare sulla Infrastruttura interoperabilità PDND gli Utenti autorizzati ad operare per proprio conto con riferimento alla gestione del singolo E-service;
- comunicare all’Erogatore tempestivamente, al più tardi entro __________, eventuali modifiche impattanti sulla stipula del presente Accordo e/o sull’accesso e sulla fruizione del relativo E-service;
- comunicare all’Erogatore tempestivamente, al più tardi entro __________, eventuali eventi impattanti sulla sicurezza relativa all’integrità e alla riservatezza della comunicazioni necessarie all’accesso e sulla fruizione del relativo E-service;
- segnalare all’Erogatore tempestivamente, al più tardi entro __________, qualsiasi malfunzionamento o disservizio riscontrato in fase di accesso e/o fruizione dell’E-service;
- in caso di violazione dei dati personali di cui è titolare del trattamento, procedere all’eventuale notifica all’Autorità di controllo e, ove necessario, alla comunicazione agli interessati in applicazione degli artt. 33 e 34 del Regolamento (UE) 2016/679 (di seguito GDPR);
- istruire adeguatamente gli Utenti, autorizzati ad agire per proprio conto, sul corretto utilizzo dell’E-service nonché sul trattamento dei dati personali, sui relativi rischi e sui diritti degli interessati;
- adottare misure tecniche e organizzative volte a garantire un livello di sicurezza adeguato al rischio, sorvegliare e tracciare l’accesso e le attività dei propri Utenti per il tempo strettamente necessario e al solo fine di tutelare la protezione dei dati personali secondo quanto definito dagli artt. 25, 29 e 32 del GDPR, informando tempestivamente l’Erogatore in caso di accesso non autorizzato, di trattamento illecito di dati e di qualsiasi minaccia che comporti un rischio per la sicurezza e per i diritti e le libertà degli interessati;
- dotarsi degli strumenti e di tutte le soluzioni informatiche necessarie ad un uso ottimale delle funzionalità di fruizione dell’E-service;
- controllare e garantire la sicurezza degli accessi all’E-service, tenuto conto che il tracciamento applicativo degli accessi e delle operazioni effettuate è svolto anche dall’Erogatore, come previsto al comma 3, lett. d, del presente articolo.
- In caso di mancato rispetto degli obblighi previsti al precedente comma da parte del Fruitore e dei suoi Utenti, l’Erogatore si riserva la facoltà di sospendere il presente Accordo, anche con effetto immediato, e l’erogazione dell’E-service.
- L’Erogatore garantisce, essendone responsabile:
- la conformità dell’E-service alla normativa vigente anche in tema di protezione dei dati personali;
- l’accesso all’E-service e la relativa fruizione da parte del Fruitore;
- l’accuratezza, l’integrità e la veridicità dei dati comunicati al Fruitore in fase di erogazione dell’E-service;
- il tracciamento degli accessi e delle operazioni effettuate, come individuati nelle Linee Guida AgID e associati alla fruizione dell’E-service, nonché la loro conservazione per il tempo strettamente necessario.
- Con riferimento alle comunicazioni dei dati tra le Parti, le stesse si impegnano al pieno rispetto della normativa unionale e nazionale in materia di protezione dei dati personali nonché a manlevarsi e tenersi indenni reciprocamente da qualsiasi perdita economica, contestazione, responsabilità, condanna o sanzione, nonché altre spese sostenute o costi subiti - anche in termini di danno reputazionale - per effetto di un’azione, reclamo o procedura intrapresa dal Garante per la protezione dei dati personali o da qualsiasi altro soggetto qualora tale azione sia conseguenza anche di una sola violazione, da parte di una delle Parti, della normativa in materia di protezione dei dati personali e/o delle obbligazioni assunte ai fini dell’esecuzione del presente Accordo.
- Le Parti si danno reciprocamente atto che gli eventuali SLA previsti nel presente Accordo saranno applicati, misurati e/o gestiti senza che ciò possa comportare alcun coinvolgimento dell’Infrastruttura interoperabilità PDND. Pertanto, le Parti concordano che anche le eventuali controversie concernenti l’applicazione, la misurazione e/o la gestione di tali SLA, saranno risolte fra le Parti, senza che l’Infrastruttura interoperabilità PDND possa svolgere alcun ruolo.
ART. 5 - Utenti autorizzati ad agire per conto del Fruitore
- Il Fruitore accede all’E-service per il tramite dei propri Utenti dallo stesso specificamente identificati e autorizzati ad agire per l’E-service.
ART. 6 - Limiti alla responsabilità
- Le Parti non sono responsabili per la mancata erogazione o fruizione dell’E-service dovuta a un malfunzionamento o disservizio della Infrastruttura interoperabilità PDND, salvo che tale evento sia dipeso da una causa alle stesse imputabili.
- Le Parti accettano e riconoscono che PagoPA S.p.A. non è responsabile per la mancata e/o per l’eventuale illecita comunicazione di dati fra le stesse.
ART. 7 - Trattamento dei dati personali
- Le Parti, in qualità di titolari del trattamento, hanno l’obbligo di operare nel pieno rispetto delle disposizioni di cui al GDPR e al decreto legislativo 30 giugno 2003, n. 196 e s.m.i. (di seguito Codice privacy) - questi ultimi nel seguito anche “normativa in materia di protezione dei dati personali”.
- L’Erogatore, in qualità di titolare del trattamento, rende accessibili i dati al Fruitore, che li tratterà in qualità di titolare autonomo del trattamento. L’accesso ai dati personali resi disponibili tramite la fruizione dell’E-service erogato attraverso l’Infrastruttura interoperabilità PDND non modifica la disciplina relativa alla titolarità del trattamento, ai sensi dell’art. 50-ter, comma 6, del CAD.
- Le Parti si danno reciprocamente atto di aver preso visione delle rispettive informative privacy.
ART. 8 - Durata, rinnovo, recesso e risoluzione
- Il presente Accordo è valido ed efficace a partire dalla data di sottoscrizione dello stesso da parte dell’Erogatore registrata tramite l’Infrastruttura interoperabilità PDND, ed ha una durata indeterminata.
- Entrambe le Parti si riservano la facoltà di recedere dal presente Accordo comunicando tale intenzione all’altra Parte, tramite l’Infrastruttura interoperabilità PDND, secondo le modalità specificate all’art. 10, con un preavviso minimo di 30 (trenta) giorni.
- Salvo diversa indicazione, il presente Accordo si applica anche in caso di predisposizione e rilascio sul Catalogo API di una nuova versione dell’E-service.
- In caso di modifiche che impattino sulla legittimità del Fruitore di accedere all’E-service e/o sulla sicurezza relativa alla integrità e riservatezza della comunicazioni necessarie all’accesso e alla fruizione del relativo E-service, l’Erogatore provvederà a sospendere l’erogazione dell’E-service e/o a risolvere il presente Accordo.
- In caso di sospensione dell’erogazione dell’E-service o cessazione del presente Accordo, l’Erogatore provvederà a disattivare temporaneamente o permanentemente la possibilità di accedere all’E-service da parte del Fruitore.
ART. 9 - Legge applicabile e foro competente
- Il presente Accordo è soggetto alla Legge italiana. Per quanto non espressamente previsto, si fa espresso rinvio al codice civile, al CAD, alle Linee guida AgID, nonchè alle altre disposizioni vigenti in materia, ivi incluse quelle in materia di protezione dei dati personali.
Se fruitore persona giuridica:
- Ogni eventuale contestazione e/o controversia che dovesse insorgere fra le Parti in relazione all’interpretazione, alla validità e/o all’esecuzione del presente Accordo, che non venisse risolta bonariamente e in buona fede fra le stesse, sarà devoluta alla competenza esclusiva del ___________________.
Se fruitore persona fisica:
- Ogni eventuale contestazione e/o controversia che dovesse insorgere fra le Parti in relazione all’interpretazione, alla validità e/o all’esecuzione del presente Accordo, che non venisse risolta bonariamente e in buona fede fra le stesse, sarà devoluta alla competenza esclusiva del giudice del luogo di residenza o domicilio del Fruitore, se qualificato come consumatore ai sensi del D.lgs. n. 206/2005. La Commissione Europea mette a disposizione dei consumatori la Piattaforma per la Risoluzione delle Controversie Online per risolvere le controversie in via stragiudiziale (Art. 14, par. 1 del Regolamento UE 524/2013). I consumatori possono presentare un reclamo al seguente link: http://ec.europa.eu/consumers/odr/.
- Nelle ipotesi in cui l’Utente non sia qualificato quale consumatore ai sensi del D.lgs. n. 206/2005, ogni eventuale contestazione e/o controversia che dovesse insorgere fra le Parti in relazione all’interpretazione, alla validità e/o all’esecuzione del presente Accordo, che non venisse risolta bonariamente e in buona fede fra le stesse, sarà devoluta alla competenza esclusiva del ___________________.
ART. 10 - Comunicazioni tra le Parti
- Ove non diversamente specificato, qualsiasi comunicazione tra le Parti inerente il presente Accordo è effettuata, tramite l’Infrastruttura interoperabilità PDND, a ciascuna delle Parti.
ART. 11 - Disposizione finali
- Le Premesse costituiscono parte integrante e sostanziale del presente Accordo e vincolano le Parti al loro rispetto.
- Le Parti, in qualità di Aderenti, si impegnano ad apportare al presente Accordo ogni modifica necessaria ad adeguarne il contenuto a qualsivoglia modifica apportata alla Lettera di Adesione.
Il Fruitore _______________ (f.to digitalmente ai sensi del regolamento eIDAS.)
L’Erogatore _______________ (f.to digitalmente ai sensi del regolamento eIDAS.)
A norma degli artt. 1341 e 1342 c.c. il Fruitore, previa lettura delle norme contenute nel presente Accordo, con particolare riguardo agli articoli 2, 4, 6, 7, 8 e 9 dichiara di approvarli, reietta fin d’ora ogni reciproca eccezione.
Il Fruitore _______________ (f.to digitalmente ai sensi del regolamento eIDAS.)