Risultati
182 risultati
-
AGID
7. 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:. 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:. 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:. 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à:. 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:. 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:. 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. ...
-
AGID
9. 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:. 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à. ...
-
AGID
3. Ciclo di vita 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. 3.1.1. 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. mermaid.initialize({startOnLoad:true});. graph TD avvio((start)) b[bozza] p[attivo] np[deprecato] e[archiviato] fine((end)) avvio --> b b --> |CANCELLA| fine b --> |PUBBLICA: tutti i campi obbligatori sono valorizzati | p b --> |SALVA| b p --> |AGGIORNA| p p --> |DEPRECA| np np --> |: nessun accordo di interoperabilità presente| e e --> fine. 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. 3.1.2. 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 ...
-
AGID
1. 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. ...
-
AGID
2. Riferimenti e sigle
Di seguito sono elencate le linee guida emesse dall’AgID che verranno espressamente richiamate nelle presenti Linee Guida. Tabella 2.4 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 ...
-
AGID
5. Data model condivisi
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 ...
-
AGID
4. Stipula dell’accordo di interoperabilità
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 ...
-
AGID
6. Categorie degli Utenti degli Aderenti
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 ...
-
AGID
3. Processo di accreditamento alla PDND
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 ...
-
AGID
1. 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. ...
-
AGID
2. Riferimenti e sigle
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 ...
-
AGID
4. 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:. 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. ...