agid / protocollo-comunicazione-aoo

Segnatura di protocollo informatico

Il file segnatura_protocollo.xsd riporta l'aggiornamento della segnatura informatica di protocollo realizzata da AgID nell'ambito delle linee guida per il documento amministrativo elettronico prodotte in attuazione dell'articolo 71 del decreto legislativo 7 marzo 2005, n. 82 e s.m.i.

Lo scambio di documenti amministrativi elettronici protocollati tra AOO vede coinvolti:

• AOO mittente, l’AOO che invia i documenti amministrativi elettronici protocollati e DEVE utilizzare uno dei canali di comunicazione indicati al capitolo “4. Modalità tecniche di trasmissione”;
• AOO destinataria, l’AOO che riceve i documenti amministrativi elttronici protocollati.

Un messaggio di protocollo, l’elemento atomico di interesse per dare seguito allo scambio di documenti amministrativi elettronici protocollati tra AOO, è una struttura logica che:

• DEVE contenere il documento amministrativo elettronico primario (di seguito documento primario);
• PUÒ contenere un numero qualsiasi di documenti amministrativi elettronici allegati (di seguito allegati);
• DEVE contenere la segnatura informatica di protocollato (di seguito segnatura informatica).

Il documento primario e gli eventuali allegati DEVONO essere formati nel rispetto delle regole di formazione dei documenti amministrativi informatici.

La segnatura informatica DEVE essere formata nel rispetto del root element SegnaturaInformatica riportato in segnatura_protocollo.xsd.

La segnatura informatica DEVE essere associata in forma permanente al documento primario e agli allegati che con esso formano il messaggio di protocollo. A tal fine l’AOO mittente:

• DEVE riportare nella segnatura informatica l'impronta (digest) del documento primario e, se presenti, degli allegati;
• DEVE assicurare l’autenticità, integrità e il non ripudio della segnatura informatica attuando le regole tecniche in materia di firma elettronica dei documenti informatici emanate dall’AgID.

La AOO mittente DEVE assicurare il controllo della validità amministrativa del documento primario, degli eventuali allegati e dei dati riportati nella segnatura informatica prima della composizione del messaggio di protocollo.

Le informazioni contenute nella segnatura informatica DEVONO essere memorizzate nel sistema di gestione dei documenti della AOO mittente e in quello delle AOO destinatarie.

Per completezza sono riportati i file:

• previous_schemas/segnatura_protocollo_circolare 28_2001.dtd, in cui è riportato il Document Type Definition relativo alla segnatura di protocollo emanato con Circolare AIPA del 7 maggio 2001, n. 28
• previous_schemas/segnatura_protocollo_circolare 60_2013.xsd, in cui è riportato il XML Schema relativo alla segnatura di protocollo emanato con Circolare AgID del 23 gennaio 2013, n. 60

IMPORTANTE

Il contenuto del presente repo è allineato con la DETERMINAZIONE N. 371 /2021 AgID che ha per oggetto "Modifiche testo Linee Guida sulla formazione, gestione e conservazione dei documenti informatici, allegato 5 - Metadati, allegato 6 - Comunicazione tra AOO di Documenti Amministrativi Protocollati ed estensione dei termini di entrata in vigore".

protocollo-comunicazione-aoo's Issues

Casi di segnature ricevute senza dati obbligatori - impronta non corrispondente e ditte individuali

Buongiorno, riepiloghiamo alcune problematiche riscontrate con Segnature nel formato NLG - Allegato 6.

1. Alcuni Enti ci inviano delle Segnature di Protocollo nel nuovo formato senza valorizzare alcuni dati obbligatori (ad es. uno spazio nel codice dell'AOO).
   Il nostro sistema non aveva previsto tale "anomalia" e quindi ci stiamo predisponendo ad aggirarlo incanalando il messaggio in un percorso differente: lo presenteremo all'Ente come una PEC senza la segnatura. Da questo processo si può comunque fare una protocollazione "assistita" ma l'operazione per l'Ente destinatario è molto più macchinosa.
   Non possiamo applicare un controllo bloccante perché l'xsd permette di introdurre tale dato sporco; caso diverso sarebbe se l'xsd non permettesse di mettere nei dati obbligatori spazi o valori vuoti: questo obbligherebbe il mittente a formare bene il messaggio prima di inviarlo.

Tale anomalia spesso maschera altri errori: se il codice aoo viene valorizzato con una stringa vuota, non riusciamo nemmeno a mandare la notifica di eccezione al mittente se necessaria.
Lasciandolo passare non segnaleremo più nulla al mittente, ed esso continuerà ad utilizzare lo stesso tracciato errato. Ci chiedevamo se altri vi hanno segnalato il problema e se come AgiD pensate di sopperire gestendo la possibilità di risposta in caso di assenza di un dato obbligatorio o se pensate di irrobustire lo schema non permettendo l'introduzione di queste casistiche.

Ci avete segnalato la issue #45 in cui sono posti temi assimilabili e da cui si evince che un caso del genere (assenza del codice univoco aoo) dovrebbe costituire un rifiuto automatico con notifica di eccezione. E' corretta l'interpretazione?

2. Un' altra casistica riscontrata riguarda la difficoltà di introdurre dei soggetti PG di tipo ditta Individuale all'interno della Segnatura di protocollo.
   Per la persona giuridica è previsto questo:

<xs:complexType name="PersonaGiuridicaType">
<xs:sequence>
<xs:element name="Denominazione" type="xs:string"/>
<xs:element name="PIVAoCF" type="prot:PartitaIVA" minOccurs="0"/>

dove però il tipo PartitaIVA è sempre lungo 11 e va bene sia per p.iva di una persona giuridica che per cf degli Enti -->es. Regione Piemonte 80087670016.

Nel caso della ditta individuale invece il codice fiscale, che la identifica univocamente, è quello del titolare (quindi un alfanumerico di 16). In alcuni casi ci viene passato solo il CF e non la partita IVA, ma nella Segnatura non possiamo introdurre il dato.

3. Caso di rifiuto automatico con notifica di eccezione al mittente.
   Ci è arrivata una segnatura in cui l'importa del documento indicata non è il base64 dello SHA256 (algoritmo dichiarato) ma il base64 dell'esadecimale dell'impronta SHA-256. Secondo le specifiche non ci sembra sia da accettare, cosa ne pensate?

Esempio
File: 001272009024070120220001.XML
Dimensioni: 1537 bytes
Impronta SHA256 (HEX): d0a59ed9396ef84711937b228445df4bca65dd8ce2d4904a382610b72d87a650
Impronta MD5: 202a08bd92162d079d1415bec36e8729
Riferimento temporale UTC: 2022-01-13T09:58:35.953Z
Impronta SHA256 (base64): 0KWe2Tlu+EcRk3sihEXfS8pl3Yzi1JBKOCYQty2HplA=
in segnatura (sembra essere il base64 dell'impronta SHA256 (HEX))
ZDBhNTllZDkzOTZlZjg0NzExOTM3YjIyODQ0NWRmNGJjYTY1ZGQ4Y2UyZDQ5MDRhMzgyNjEwYjcyZDg3YTY1MA==

4. Tra gli algoritmi previsti per l'impronta ci sono anche gli HMAC ma per usarli (e per generare l'impronta per la verifica) dobbiamo avere una chiave. In quale tag / attributo è previsto si trovi questa chiave?

Ringrazio per la collaborazione
Saluti
Alessandra

Aggiornamento Linee guida - Richiesta chiarimento su proroga

Buongiorno, vi chiediamo un chiarimento in merito alla comunicazione proroga dell'entrata in vigore delle linee guida.
In particolare le precedenti disposizioni indicavano che "le regole tecniche sono in vigore dal 10 settembre 2020 e da attuare entro il 7 giugno 2021" mentre l'attuale comunicazione individua "la data di entrata in vigore delle Linee guida e relativi allegati, precedentemente fissata al 7 giugno 2021, al 1 gennaio 2022".

Risultando le precedenti regole tecniche già in vigore, vi richiediamo pertanto conferma che l'1/1/2022 sia da intendersi come data ultima per l'adozione delle nuove specifiche.

NON TECNICO: proposta di intenti

C'è possibilità di qualche spiraglio di apertura, approfittando della riscrittura REST delle API, per inserirci qualche feature che renda il più' possibile standard l'interoperabilità interna di protocollo?

Interna = da un software dell'amministrazione che produce un output documentale al protocollo informatico della stessa amministrazione? Caso d'uso: protocollare i verbali di violazione al codice della strada.
La comunità di chi opera nella p.a. avrebbe suggerimenti al riguardo. Si tratterebbe, per dire, di avere una versione sincrona delle API che consenta di specificare altri parametri/metadati per la gestione del documento (smistamento, responsabile, classifica e fascicolo di destinazione). Poi dopo ci si accompagnerebbero altre API utili (ricerca e creazione di fascicoli e repertori, estrazione di titolario, estrazione di organigramma se non lo si prende da IPA ecc.).

Diversamente per gli enti il mero passaggio a REST non crea grossi benefici né aumenta l'appeal del protocollo interoperabile via API: tanto vale restare alla PEC. Anche la conquista del contributo PNRR (almeno per i comuni) resta un obiettivo fine a se stesso visto che in buona parte va impiegato per pagare il fornitore...

Chiarimento voce di classifica in segnatura

Analizzando la segnatura ci risulta che è possibile indicare un solo valore di classifica, nella vecchia era invece una lista.
A livello archivistico questo non è corretto in quanto un protocollo può avere più classifiche.
Questo ci sembra una discreta limitazione anche poi per la fase di fascicolazione.

Richiesta approfondimenti su Allegato 6 Comunicazione tra AOO di Documenti Amministrativi Protocollati

Individuazione del canale di comunicazione tra web services e PEC.
La necessità è di approfondire la modalità di individuazione del canale di comunicazione, tra web services e PEC.
A questo proposito la richiesta è di avere indicazioni sulla modalità di individuazione delle Aoo per cui si rende necessaria la spedizione tramite web services (ad esempio se ci sono casistiche e/o tempistiche in cui si identifica come vincolante l’utilizzo di questo canale) e se, per tali comunicazioni, esiste un vincolo di ricevere la risposta tramite il medesimo canale oppure se viene ammessa la possibilità di inviare le conferme, ecc… tramite il canale della PEC.

Interscambio messaggi di ritorno
Vi chiediamo inoltre indicazioni sulle modalità, ed eventualmente su WSDL di riferimento, per l'interscambio dei messaggi di ritorno (es. conferma ricezione, ecc...) in caso di utilizzo dei web services come canale di comunicazione e le modalità di gestione di risposte sbagliate da parte del web services del destinatario.

Disponibilità di ambiente di test
Vi chiediamo inoltre la possibilità di avere a disposizione un vostro ambiente di test da utilizzare per poter validare gli adeguamenti alle linee guida per entrambi i canali di comunicazione.

Applicazione delle LG del documento informatico: allegato 6

Un primo test di migrazione delle informazioni contenute nella segnatura di protocollo a norma circ. 60 verso il modello definito nell’allegato 6 delle LG mi ha fatto nascere alcune domande:

Messaggi di ritorno

Nella circolare 60 il capitolo 8.3 era dedicato alla Struttura messaggi di ritorno scambiato tramite posta elettronica.

Nel caso la modalità di trasmissione sia posta elettronica quale deve essere la struttura dei messaggi di ritorno del protocollo informatico della AOO destinataria per soddisfare tutti i casi d’uso previsti dai flussi di comunicazione?

Riferimenti esterni

Nella circolare 60 “Un messaggio protocollato può contenere riferimenti esterni a documenti informatici reperibili per via telematica, […] Tali riferimenti esterni possono riguardare sia il documento primario che i documenti allegati .”
Questa soluzione consentiva di gestire la trasmissione di documenti di grandi dimensioni sia tramite Posta elettronica, sia tramite Webservices in modalità asincrona senza incorrere in limiti del gestore di PEC e in timeout della comunicazione

Come è possibile gestire questa modalità di comunicazione rispettando le specifiche dell’allegato 6?

Elemento Riferimenti

La circolare 60 prevedeva la presenza nel file di segnatura di un elemento Riferimenti, attraverso la quale era possibile fare riferimento a un messaggio precedentemente inviato dal destinatario per consentirgli la fascicolazione automatica del nuovo messaggio (Riferimenti/Messaggio/Identificatore)

Come è possibile gestire questa modalità di comunicazione rispettando le specifiche dell’allegato 6?

Elemento Riservato

La circolare 60 prevedeva la presenza nel file di segnatura di un elemento Riservato: Esprime la richiesta di trattamento riservato del messaggio protocollato. Può contenere un testo che descrive i motivi della richiesta.

Come è possibile gestire questa modalità di comunicazione rispettando le specifiche dell’allegato 6?

Elemento ContestoProcedurale

La circolare 60 prevedeva la presenza nel file di segnatura di un elemento ContestoProcedurale: Indica un riferimento ad un contesto procedurale ovvero lo svolgimento di un generico complesso di attività amministrative in qualche modo collegate. Attraverso il quale era possibile individuare la tipologia di procedimento alla quale si riferisce il messaggio (e, di conseguenza, gestire inoltri automatici).

Come è possibile gestire questa modalità di comunicazione rispettando le specifiche dell’allegato 6?

Elemento PiuInfo

La circolare 60 prevedeva la presenza nel file di segnatura di un elemento PiuInfo: L’elemento opzionale “PiuInfo” contiene ulteriori informazioni, che non è possibile associare ad altri elementi, relative all’elemento padre cui si riferisce. Qualora due o più amministrazioni stabiliscano di scambiarsi informazioni non previste tra quelle definite, esse possono estenderle con le informazioni specifiche stabilite di comune accordo utilizzando questo elemento.

Come è possibile gestire questa modalità di comunicazione rispettando le specifiche dell’allegato 6?

CHIARIMENTO: PEC protocollo di comunicazione immutato

La possibilità di utilizzare la modalità di comunicazione tramite posta elettronica certificata (PEC) è da intendersi quale modalità residuale in attesa che tutte le AOO provvedono ad attrezzarsi con gli opportuni strumenti per l’utilizzo dei WS SOAP.

L’intenzione nel predisporre l’allegato è stata quella di favorire l’adozione della modalità di comunicazione tra AOO realizzata tramite WS SOAP.

Il protocollo di comunicazione, comprensivo degli oggetti dei messaggi scambiati, per le comunicazioni tramite PEC resta immutato rispetto a quanto indicato nella Circolare AgID 60/2013, fatta salva la sostituire del type nel namespace http://www.digitPa.gov.it/protocollo/ con il type nel namespace http://www.agid.gov.it/protocollo/.

La segnatura XML

MI sembra di capire che la segnatura XML da linee guida vigenti sopravviva, ma semplicemente, con la chiamata POST all'API che risponde al percorso /destinatario/inoltro, venga passata codificata in BASE64.
Però:

• non si crea una duplicazione con possibili incongruenze fra documento principale e allegati (con relative impronte) dichiarati nella segnatura XML e i documenti dichiarati nel payload della chiamata POST?

Fra l'altro, sarebbe stato lecito attendersi che la segnatura del protocollo interoperabile, da file XML autonomo, divenisse il JSON stesso veicolato nel payload della chiamata. Tuttavia ha anche un senso mantenerlo come file autonomo, sigillato e validabile contro un XML schema, più facilmente riusabile anche in chiave di validazione dei documenti trasmessi. E' questa la ratio della scelta?

Richiesta di intervento a salvaguardia delle comunicazione fra AOO

Chiedo un intervento autorevole per porre fine a un problema che affligge gli scambi di messaggi via PEC fra AOO.

Partiamo dalla premessa che lo scambio via WS non ha preso piede. E che quindi la segnatura.xml viaggia per PEC (o e-mail, ma diciamo PEC).

Ora fra linee guida, allegato e non so che altro, viene fuori che un messaggio con segnatura non conforme deve essere scartato. Ciò vuol dire che va buttato via senza nemmeno aprirlo e giusto mandando una notifica di eccezione al mittente.

Una simile perentorietà è applicabile e sostenibile solo se si usano i WS che danno un riscontro immediato: segnatura non conforme, non passi, sai che devi rimandare la comunicazione.
Con la PEC crea invece danni: alcune amministrazioni "chiudono un occhio" (pur sapendo di andare contro la regola), altre sono del tutto tassative e si rischiano davvero di perdere comunicazioni importanti, che fuori di un contesto di interoperabilità (di nome) sarebbero del tutto valide...

Potete fare qualcosa per invitare le amministrazioni a non scartare messaggi PEC con errori nelle segnature?

Servizio per validazione segnatura rispetto ai file inviati

Salve,
esiste un servizio per validare una segnatura anche rispetto ai file inviati?
Intendo: non solo correttezza formale dell'xml ma anche rispondenza delle impronte.

Chiedo perché ho un problema di continue eccezioni da un ente (solo lui) per impronte anomale e sarebbe utile capire chi sta sbagliando.

Dubbi emersi in fase di analisi per l'adeguamento della segnatura

Siamo a richiedere approfondimenti rispetto ad alcune situazioni riscontrate in fase di adeguamento alla nuova versione della segnatura.

1. Il destinatario è diventato un SoggettoType che può essere:
   xs:choice
   <xs:element name="Organizzazione" type="prot:OrganizzativaType"/>
   <xs:element name="Persona" type="prot:PersonaType"/>
   </xs:choice>

ovvero in alternativa Organizzazione o Persona
L'organizzazione è così definita
xs:sequence
<xs:element name="Riferimento" type="prot:NomeOrganizzazioneType"/>
<xs:choice minOccurs="0">
<xs:element name="UnitaOrganizzativa" type="prot:OrganizzativaType"/>
<xs:element name="Persona" type="prot:PersonaType"/>
</xs:choice>
</xs:sequence>
ovvero un riferimento ad un' "organizzazione" che è caratterizzata dal nome dell'organizzazione e, quando esiste, il codice IPA della stessa e opzionalmente unità organizzative o persone.

In pratica riscontriamo come sia scomparso il riferimento ad amministrazione e aoo: una sola delle due può essere referenziata e nel caso della aoo, il cui codiceIPA non è univoco, non ci permette di risalire al destinatario.
Non abbiamo inoltre trovato nemmeno alcun riferimento all'indirizzo telematico dei destinatari, rendendo in questo modo meno leggibile la segnatura.

2. sempre nei destinatari, in caso di destinatario che non sia una Amministrazione, è presente solo il tag Persona che ha obbligatori nome e cognome e facoltativo codice fiscale (con pattern specifico) ma non partita iva (necessaria in caso di comunicazione di aziende).

3. nella produzione di un destinatario come persona, se si specifica l'indirizzo postale, abbiamo riscontrata l'obbligatorietà del codice istat del comune.

Dubbi sull'applicabilità del sistema di interoperabilità

Buongiorno,
scrivo in qualità di analista di un sistema di protocollo informatico e gestione documentale, distribuito su più di 3000 scuole. In fase di analisi e sviluppo sono emerse una serie di criticità relativi alla gestione dell’intero flusso di comunicazione: in particolar modo il non avere garanzia della correttezza delle implementazioni effettuate dal sistema mittente e dal sistema ricevente, aggrava la complessità del processo con ripercussioni sia sul provider del servizio che sull’utenza (operatori del servizi amministrativi delle pp.aa), di fatto costretti a monitorare due canali (pec/domicilio digitale e il sistema ws di interoperabilità).
Desideravamo sapere se è in previsione (ed eventualmente con quali tempistiche):

• un ambiente di test
• verifica tecnica da parte dell’AgID della correttezza delle implementazioni e validazione degli endpoint registrati nell’IPA
• percorso di certificazione dell’implementazione

Riguardo poi al sigillo elettronico, si prevedono delle convenzioni per l’acquisto da parte delle pubbliche amministrazioni con i fornitori qualificati?
Nel caso di messaggio protocollato inviato per pec istituzionale, c’è comunque obbligo di firma del file di segnatura con sigillo elettronico?
La pec, se indicata peraltro come domicilio digitale, non dovrebbe garantire origine e integrità del messaggio, rendendo superflua la sottoscrizione con sigillo elettronico?
Per ultimo, desideravamo sapere se è prevista (e con quali tempistiche) l’implementazione di servizi rest in sostituzione dei soap

Cordialmente

Versione definitiva della Segnatura_protocollo.xsd da utilizzare

Buongiorno,
abbiamo la necessità di sapere qual'è la versione definitiva della Segnatura da utilizzare per gli sviluppi.
Dal 07 giugno stando alla Normativa, riceveremo la segnatura nel nuovo formato, che però ad oggi non è ancora completamente definito.

Quale formato di segnatura_protocollo.xsd è da considerarsi quella da utilizzare?

La versione sul ramo master è di settembre 2020,
quella del ramo bug-fix, che abbiamo concordato di usare nell'incontro con voi, è ora modificata e non è ancora stata
ufficializzata.

Abbiamo visto comparire una precisazione sul codice aoo nell'identificativo della segnatura:
--> codiceAOO, il codice IPA dell'AOO (attributo cod_uni_aoo dell’entità AOO dell’IPA)
Questo ci crea un po' di problemi perchè nella precedente Segnatura da Circolare 60 il codiceAOO non era il nuovo codice univoco aoo di 7 caratteri definito da IPA nelle recenti comunicazioni (la modifica comporterebbe ulteriori valutazioni perchè non è riconducibile a quanto avveniva in passato).

Abbiamo anche altre necessità da chiarire:

• il codice fiscale / p.iva della PG, nella versione da cui siamo partiti era in alternativa.
  Abbiamo progettato la nostra base dati per recepire entrambi i valori mentre ora sono stati accorpati e non capiamo come distinguerli.
• è comparso l'elemento AmministrazioneEstera che non avevamo previsto di gestire.

Ogni change per noi comporta delle modifiche.

Per rispettare le scadenze di giugno potreste darci la data di pubblicazione definitiva, nella quale il ramo bug-fix
diverà master?

Sarebbe inoltre possibile indicare un numero di versione differente sulla versione master e sulle versioni che si susseguono in bug-fix per poter anche a posteriori identificare versioni di segnatura differenti dalla corrente ma che, in un momento storico, sono state per così dire ufficiali?
Ci potrebbe tornare utile per identificare ora e a tendere le variazioni.

Cordiali Saluti

Allegato 6 & PDND

Si propongono alcune considerazioni e richieste di chiarimento circa l’aggiornamento in corso dell’Allegato 6 delle Linee guida Agid sulla formazione, gestione e conservazione dei documenti informatici e PDND Piattaforma digitale nazionale dati.

Viste le nuove le specifiche OpenAPI delle interfacce REST per il dialogo diretto tra i sistemi di protocollo informatico delle PA,

considerati l'obbligo per le PA di accreditarsi a PDND (CAD Art. 50 ter e Decreto 22 settembre 2022), l’Avviso PNRR Misura 1.3.1 "Piattaforma Digitale Nazionale Dati" dedicato ai comuni, per il quale DTD e ANCI hanno individuato come caso d’uso lo scambio dei documenti protocollati secondo le specifiche dell’All. 6, e le modalità di funzionamento di PDND che assicura il trust machine-to-machine tra sistemi informatici degli aderenti e sistemi informatici della Infrastruttura PDND, si elencano alcuni punti che si ritiene utile definire in modo chiaro ed esplicito nell’aggiornamento dell’All. 6:

1. realizzazione dell’implementazione delle interfacce di Protocollo esclusivamente tramite PDND. Il fine è evitare ambiguità e l'eventuale realizzazione del servizio in tre modalità differenti (REST “diretto”, SOAP “diretto” e in PDND), incluse le infrastrutture informatiche specifiche e necessarie per il funzionamento del servizio stesso

2. con il tramite esclusivo di PDND, si ritengono superati e non più necessari

   • individuazione dell’endpoint da indicare per ciascun ente nella relativa scheda IPA (All. 6, 3. Flussi di comunicazione, pag. 10 e 5. APPENDICE B)
   • implementazione specifica del WS Security (All. 6, 5. APPENDICE B, pag. 27)

3. utilizzo della sola modalità REST per l’interoperabilità di Protocollo, nonostante PDND consenta l’impiego anche di SOAP. La proposta è motivata dal fatto che si tratta di un servizio nuovo, in fase di realizzazione da parte degli enti e pertanto si può escludere l’esistenza di servizi già realizzati in SOAP; l’eventualità di implementare e gestire il medesimo servizio in entrambe le modalità risulterebbe estremamente onerosa.

Si evidenzia inoltre che il modello che sta alla base di PDND appare di difficile applicazione nell’interoperabilità del Protocollo. Ogni ente sarà al contempo erogatore e fruitore: come erogatore dovrà pubblicare l’e service dedicato al Protocollo e risulterà anche fruitore per il medesimo servizio di Protocollo pubblicato dall’ente con il quale sta scambiando il documento da protocollare. Nella fase iniziale di avviamento del servizio di Protocollo sarà necessario verificare e provvedere a molteplici e “incrociate” iscrizioni agli e service (richiesta, gestione, approvazione), con l’inevitabile rallentamento e complessità delle attività di protocollazione dell’ente.

Pertanto per limitare le criticità operative determinate dal flusso erogatore/fruitore di PDND, si ritiene auspicabile una semplificazione con l’introduzione di automatismi e/o la modifica del flusso erogatore/fruitore per gli e-service di Protocollo.

Codice AOO vs Codice_uni_aoo

Cosa si intende in segnatura per "CodiceAOO"?
Il "vecchio"codice AOO che è sempre stato presente in IPA oppure quello che adesso viene definito in IPA Codice_uni_aoo?

Esempio Regione Toscana Giunta:
Codice AOO: AOOGRT
Codice_uni_aoo: A03E926

Nell'attuale segnatura è sempre stato indicato il codice AOO che poi nei software di protocollo deve essere associato al registro di protocollo?

Link WebService su IndicePA

Buongiorno,
in prospettiva di dover aggiornare il link webservice della propria AOO e di conseguenza anche reperire quelli delle altre PA, ci sarà una nuova sezione su IndicePa da compilare? Ora non compare ancora nulla

Quesito su allegato 6 - memorizzazione della conferma di protocollazione del messaggio di protocollo nel registro di protocollo

Quando una Amministrazione Interoperabile mittente scrive ad un'altra Amministrazione Interoperabile destinataria, l'Amministrazione destinataria risponde con la "conferma di protocollazione del messaggio di protocollo" a questo punto L'AOO mittente cosa deve fare?
Deve protocollare a sua volta la ricevuta di protocollazione del destinatario o come previsto per le notifiche PEC va solo memorizzata ed associata al protocollo in uscita senza nuova protocollazione?

Lo scenario che crea il dubbio maggiore è questo, se una AOO centrale scrive alle sue AOO, territoriali che potrebbero essere centinaia (es Ragionerie territoriale, Agenzie, Corti tributarie), in modalità interoperabile queste risponderebbero ognuna con la propria conferma di protocollazione, se il mittente dovesse protocollare a sua volta tutte queste conferme, a fronte di un protocollo in uscita dovrebbe generare centinaia di protocolli in ingresso.

Il punto riportato nell'allegato indica "Deve memorizzare" non specificando se questa attività deve essere svolta con una registrazione di protocollo automatica o impostando una semplice relazione.

.......AOO mittente: Ricezione della conferma di protocollazione del messaggio di protocollo Nel caso in cui l’AOO destinatario non segnali anomalie l’AOO mittente DEVE memorizzare la conferma di protocollazione del messaggio di protocollo nel registro di protocollo per assicurare la persistenza dello stesso. Nel caso in cui l’AOO destinatario segnali anomalie l’AOO mittente DEVE ritenere la transazione non conclusa.

Resto in attesa di una gradita risposta.

Charimenti interoperabilità e linee guida sicurezza

Salve,
avrei bisogno di chiarimenti in merito alla gestione della sicurezza nello scambio di messaggi SOAP.
La parte relativa a TLS, versione minima, etc è chiara.
Se ho capito bene per lo scambio dei messaggi SOAP è necessario attenersi al profilo [INTEGRITY_SOAP_01] che prevede, tra le altre cose, l'inclusione/riferimento
del certificato X.509 e la firma del payload. E' corretto?

Il certificato da utilizzare dovrà essere qualificato in modo da includere gli OID (2.5.4.97 e l'OID 2.5.4.11) definiti nelle linee guida. A questo scopo è possibile
utilizzare il medesimo sigillo informatico utilizzato per la firma della segnatura?

Chi riceve il messaggio SOAP dovrà identificare il "mittente" tramite il certificato e tramite la verifica sull'IPA. E' corretto? Nel caso in cui cui la verifica
non sia possibile per mancanza di tali informazioni nel certificato, il messaggio deve ritenersi non valido?
Se invece tali informazioni ci sono, ma per problemi tecnici non sia possibile verificare lato IPA, il messaggio è sempre da scartare?

Prospettive uso API via PDND

Salve, non saprei dove altro chiedere.
Visto che come Comune dobbiamo decidere adesso se e come spendere contributo PNRR per diventare erogatori PDND e visto che dobbiamo fare i conti anche con la sostenibilità economica e tecnica degli interventi che commissioniamo adesso (il PNRR fra due anni non c'e' più), chiedo:

• è confermato che la modalità di fruizione delle API REST del protocollo interoperabile sarà uguale a quella delle altre API esposte su PDND, quindi previo accordo di fruizione fatto ad hoc? Oppure e' allo studio qualcosa per automatizzare la cosa?

Sarebbe urgente saperlo, perche' se vanno fatte 30mila richiesta di interfaccia PDND evito volentieri di attivare le API REST del protocollo interoperabile.

Apertura consultazione Linee Guida Tecnologie e standard per la sicurezza dell’interoperabilità tramite API dei sistemi informatici

A fronte della pubblicazione in consultazione delle "Linee Guida Tecnologie e standard per la sicurezza dell’interoperabilità tramite API dei sistemi informatici" (https://www.agid.gov.it/it/agenzia/stampa-e-comunicazione/notizie/2021/04/19/api-consultazione-linee-guida) ci sembra che le specifiche per riuscire a implementare correttamente le interfacce di servizio SOAP dell'Allegato 6 siano ancora "non definitive".
In questo quadro come si inserisce la scadenza di giugno?
Non ritenete che nello scenario sopra descritto l'unico cosa "certa" rimane lo scambio di messaggi tramite PEC? Che invece avevamo capito dover essere residuale rispetto ai servizi.

mittente / destinatario

Sarà perché manca una guida testuale del processo, un aggiornamento dell'allegato 6 insomma, ma personalmente trovo fuorviante e di difficile comprensione "mittente" e "destinatario" negli URL degli endpoint.
Quale e' il punto di vista adottato?

Allegato 6: dubbi emersi in fase di analisi delle nuove linee guida

Come da precedenti contatti riepiloghiamo le questioni emerse negli scambi con voi (AgiD) a beneficio di chi dovrà analizzare l’allegato 6. Dividiamo le domande per tematica.
Le domande contrassegnate con [*] sono emerse in seguito ai precedenti confronti (o sono state integrate con nuovi dettagli).

1. IPA – Indice Pubbliche Amministrazioni
1.1 Recupero domicilio della AOO da IPA e comunicazione end-to-end
Per scambiare un messaggio tra AOO prenderemo il tipo domicilio da IPA. Nelle API di IPA che riportano il domicilio (rif. http://www.indicepa.gov.it/public-ws/WS09_DOM_DIG_AOO.php) esiste la tipologia del domicilio (per ora solo PEC) e il domicilio digitale della AOO. Verrà aggiunta un’informazione contenente gli endpoint dei ws soap mittente e destinatario?
Se presenti manderemo il messaggio come definito nel wsdl: lo manderemo direttamente all'endpoint della AOO destinataria (che sarà un servizio esposto su Internet in https da una AOO di altro Ente) senza l’intermediazione delle porte spCoop. È corretto?

1.2 IPA – modalità di accesso ai dati
IPA ci ha comunicato che non sarà più aggiornata la modalità di fruizione attraverso LDAP. Continueranno ad essere disponibili Open Data e API. Sarà messa a disposizione una nuova fruizione via SPARQL che però ci sembra non essere ancora disponibile.
Via Open Data è necessario scaricare ogni volta tutti i dati. Non esiste una modalità incrementale. Sarà disponibile con la fruizione via SPARQL? Quando se ne prevede la disponibilità?

1.3 Aggiornamento endpoint su IPA – dove pubblicheremo l’endpoint del servizio?
Attualmente nei dati di IPA è presente il tipo domicilio e l’indirizzo PEC. NON è previsto un campo specifico per i servizi. Verranno utilizzati gli stessi campi (più riferimenti di diverso tipo per la stessa AOO) oppure ci saranno degli attributi specifici?
L’AOO potrà avere più domicili della stessa tipologia? Oppure avrà una PEC e una coppia di endpoint per invioMessaggio e invioConferma?

1.4 [*] Politiche di retry e switch da un canale ad un’altro
Quali sono le politiche di retry? Nel caso di esistenza di entrambi i domicili per una AOO (sia servizi SOAP che PEC) e assunto che la tipologia prioritaria per la comunicazione sarà servizi, è previsto che si facciamo una serie di tentativi su un canale e poi si passi al secondo canale in caso di indisponibilità del primo? Quanti sono i tentativi da effettuarsi? Ci sono casi in cui dopo il primo tentativo si può assumere che con tale canale non otterrò mai risposta (mancata configurazione)?
Potrò ottenere dai servizi risposte tipo “Sistema non disponibile, riprova tra 10 minuti? Oppure i tentativi sono da intendersi sequenziali in un tempo massimo che può essere costituito dal timeout?

2 SIGILLO ELETTRONICO
2.1 [*] Sigillo Elettronico: si tratta di un sigillo unico per tutto l’Ente o uno per AOO?
Il Sigillo è da intendersi per AOO o per Ente in qualità di soggetto giuridico?
Se fosse per AOO, ogni volta che una AOO viene chiusa dovrebbe essere applicato un processo di revoca sigillo per la aoo vecchia e richiesta sigillo per la aoo nuova. Ci sono Enti che hanno molte AOO.
Possono essere rilasciati più Sigilli per lo stesso Ente?

3 AMBIENTE DI TEST E COLLAUDO
3.1 Esiste un ambiente di test e se si quali sono le modalità per attivarlo?
Tale domanda è riferita sia ad IPA che a controparti di Enti che vorrebbero provare il loro servizio prima della messa in produzione.

3.2 È previsto un collaudo dei servizi dell’Ente prima che questi vadano in produzione?
AgiD prevede di verificare quanto implementato non tanto in termini di implementazione stessa, ma di SLA che il servizio deve garantire. Quale può essere un tempo di risposta accettabile?

4 WS SOAP INTEROPERABILITA’ e PEC
4.1 [*] Possiamo essere certi che chi implementa MessageInoltroResponse implementi anche la ConfermaMessaggioInoltro?
La conferma, seppure asincrona, chiude il ciclo di una comunicazione avvenuta correttamente. È presumibile che in seguito ad essa sui nostri sistemi possa succedere qualcosa.
Se arrivasse il messaggio ma non la conferma cosa si dovrebbe fare? Rimandare il messaggio? E quindi lato ricezione prevedere anche che potrebbe arrivare due volte la ricezione e che quindi la seconda verrà scartata.
Supponendo un cruscotto di gestione dei messaggi avremo un cambio di stato in “preso in carico dalla AOO destinataria” quando otterremo la response sincrona MessageInoltroResponse, e un “ricevuta correttamente dalla AOO destinataria” in seguito alla nostra ricezione di una request ConfermaMessaggioInoltro con al suo interno un esito positivo. Se questo secondo messaggio non dovesse arrivare è previsto o si prevederà un modo per “richiedere” lo stato di ricezione (magari su un gruppo di messaggi?)

4.2 Le PEC verso i privati. Il titolo della sezione rimanda solo alla comunicazione tra AOO.
La PEC verso i privati continuerà ad essere un canale valido? E se sì, dovranno avere la stessa Segnatura descritta nell'allegato 6? Nel vecchio xsd della Segnatura c'erano le istruzioni per l'invio delle notifiche di annullo ad es. Nel nuovo xsd le ricevute non ci sono più. L’annullo da parte di mittente o destinatario è gestito come messaggio a parte.

5 MESSAGGIO PROTOCOLLO XSD
5.1 [*] Relazione 1:1 tra Documento e contenuto fisico
Il messaggio di protocollo (MessaggioProtocolloType) ha al suo interno, oltre alla segnatura, il Documento stesso che è di tipo FileType
<xsd:element name="Documento" type="msgprot:FileType"/>
che corrisponde al contenuto fisico. Non sarebbe più “versatile” avere uno o più Contenuti all’interno del Documento e caratterizzare loro come FileType anziché il documento stesso? Rispetto alla nostra struttura attuale ci semplificherebbe alcune casistiche come quella descritta nel punto successivo (marca e firma detached).

5.2 [*] Marca detached e Firma detached
Nel caso di documento con marca temporale detached...come possiamo fare? C'è la possibilità di marcare un unico documento principale (che è 1:1 con un contenuto fisico). La marca però non può essere considerata un allegato a nostro avviso e altrettanto la firma. Potremmo avere più marche e più firme a fronte di un documento.

6 SEGNATURA XSD
6.1 Nel nuovo xsd della Segnatura manca la possibilità di indicare se il destinatario è una persona giuridica (si faccia riferito a SoggettoType)

6.2 Link e gestione messaggi di grandi dimensioni
Nella versione della Segnatura attuale, per il documento si può indicare un link nel formato url da cui reperire un documento, in alternativa ad allegarlo alla mail PEC (per file audio, video ad es. con dimensioni non inviabili). Per i servizi avremo lo stesso problema in assenza del link.
Nella nuova Segnatura non c'è più la possibilità di definire tali link. Come possiamo gestire questa casistica?

6.3 [*] Perché il tag <CodiceFiscale> non è obbligatorio quanto invece lo si richiede obbligatorio nei metadati descritti nell’allegato 5?

6.4 [*] Perché il sottotag della Segnatura <IndirizzoTelematico> del tag <Persona> è obbligatorio?
Non tutti i cittadini hanno un indirizzo telematico: se un cittadino dovesse portare un’istanza a mano presso uno sportello dell’Ente potrebbe non essere disponibile tale informazione.

6.5 [*] Nei procedimenti amministrativi in cui la protocollazione in uscita è un portale, dove / come censiamo questa informazione?
Potrebbe essere ricondotta all’ <indirizzoTelematico> indicato nella Segnatura?
E in tal caso sarebbe di tipo url o other? - url, nel caso di interfacce di servizio (API REST o SOAP) o - other, in casi differenti dai precedenti
Supponiamo il caso in cui un domani sull’app IO il cittadino dovesse recuperare un procedimento amministrativo fatto presso l’Ente.

6.6 [*] Tutti i sotto tag di <IndirizzoPostale> devono essere compilati minuziosamente oppure potremo alimentare solo quelli che ho e aggirare l’obbligatorietà mettendo un tag vuoto?

6.7 il sottotag del tag <IndirizzoPostale> non sarebbe più corretto chiamarlo <Stato> per gestire anche il caso di apolidi? Osservazione riportata dagli Enti

Bug fix in progress, view branch fixbug-2021

Si segnale che è in realizzazione il bug fix sul branch https://github.com/AgID/protocollo-comunicazione-aoo/tree/fixbug-2021

Segnatura.xml e protocollo REST

Condividiamo molti dei temi già trattati dalle numerose issues pubblicate, ma ci preme evidenziare un tema molto importante che ancora oggi sembra non essere maturo, è il tema della segnatura.xml e della sua elaborazione, alla base dell’interoperabilità e della sua futura evoluzione nel protocollo REST.

L'interoperabilità tra le Pubbliche Amministrazioni è un obiettivo cruciale per garantire una comunicazione efficace e senza intoppi. Oltre alla scelta del canale di comunicazione, come REST, SOAP o PEC, un elemento fondamentale per l'interoperabilità è l'esattezza dei dati presenti nella segnatura di protocollo.

La segnatura di protocollo svolge un ruolo centrale nello scambio di documenti amministrativi protocollati tra le Aree Organizzative Omogenee (AOO). Tuttavia, dalla nostra esperienza di software house, verifichiamo continuamente la presenza di dati inaccurati o inconsistenze all'interno di essa, i quali possono compromettere l'interoperabilità e causare errori di interpretazione o trasmissione dei dati.

Pertanto, oltre a considerare la tipologia di canale di comunicazione più appropriato, è fondamentale dedicare attenzione alla corretta strutturazione e validità dei dati nella segnatura di protocollo. Ciò implica la verifica dei dati, la validazione rispetto allo schema specificato e la conformità alle specifiche stabilite dalle Linee Guida.

La validazione dei dati comporta la rimozione di caratteri non validi, la correzione di errori di formattazione e la gestione di elementi indesiderati. Inoltre, è essenziale che i dati siano aggiornati e coerenti con l'Indice dei domicili digitali delle pubbliche amministrazioni e dei gestori di pubblici servizi (IPA), come richiesto dalle normative.

Sulla base delle linee guida dell'Allegato 6 e con l'obiettivo di migliorare l'interoperabilità e garantire la corretta gestione dei dati nella segnatura di protocollo, si propone l'introduzione del parsing obbligatorio della segnatura di protocollo. Dalla nostra esperienza è evidente che in tantissimi casi non venga fatto.

Il parsing dovrebbe essere effettuato sia lato mittente (prima dell'inoltro) che lato destinatario, utilizzando gli schemi XSD forniti nelle specifiche. In particolare, il parsing lato destinatario dovrebbe essere eseguito come parte del processo di ricezione dei documenti amministrativi protocollati.

Se il parsing ha esito negativo, il sistema destinatario deve generare un errore che comunica al mittente che la segnatura generata non rispetta lo schema XSD indicato nelle linee guida.

L'inserimento di questa verifica obbligatoria contribuirà ad aumentare la conformità e la qualità dei dati nella segnatura di protocollo, riducendo la possibilità di errori di interpretazione o di trasmissione dei dati. Inoltre, consentirà di identificare tempestivamente eventuali non conformità e di comunicare al mittente le correzioni necessarie per una corretta elaborazione.

Nel processo di comunicazione REST, si suggerisce di effettuare il parsing obbligatorio della segnatura di protocollo subito prima di verificare la firma della segnatura.

La verifica della firma digitale garantisce l'integrità e l'autenticità dei dati nella segnatura di protocollo. Tuttavia, prima di effettuare questa verifica, è importante assicurarsi che la segnatura di protocollo sia strutturata correttamente e rispetti lo schema XSD specificato nelle linee guida.

Quindi, se si verifica un errore durante il parsing della segnatura di protocollo, il sistema dovrebbe generare una risposta che indica una "anomalia di parsing XML" nella segnatura. Questa risposta dovrebbe essere inviata al mittente del messaggio per informarlo dell'errore e della non conformità della segnatura rispetto allo schema XSD indicato nelle linee guida.

In questo modo, si promuoverà una maggiore affidabilità e precisione nella gestione dei dati nella segnatura di protocollo, migliorando l'interoperabilità tra le AOO e facilitando una comunicazione senza intoppi.

Allegato 6 - Dubbi - Schema XSD PEC protocollo di comunicazione

Buongiorno

leggendo l'allegato 6 delle linee guida sulla formazione, gestione e conservazione non mi sono chiari i seguenti aspetti:

il nuovo schema XSD per la segnatura (appendice A dell'allegato 6) si utilizzerà solo per l’utilizzo dei WS SOAP?
Nel periodo transitorio invece, in attesa che tutte le AOO provvedono ad attrezzarsi con gli opportuni strumenti per l’utilizzo dei WS SOAP, si continuerà ad utilizzare la modalità di comunicazione tramite posta elettronica certificata (PEC) con lo schema XSD previsto dalla Circolare AgID 60/2013?

Grazie
Cordiali saluti

bearerAuth e PDND

Sfogliando le specifiche tutti i servizi esposti prevedono come security il bearerAuth, cioè il token JWT ottenuto dalla PDND che opera come identity provider.

Domanda di sostenibilità, 1: si intende che ogni p.a. crei un client e-service PDND per ogni possibile p.a. destinataria di comunicazioni? O sono previste modifiche sostanziali nelle logiche di funzionamento della PDND?

Sempre in tema di PDND, premesso che probabilmente in un catalogo API come quello associato alla PDND io mi attenderei di trovare un'unica voce "API del protocollo interoperabile ella p.a. italiana" e non totmila voci "Ente X - protocollo interoperabile", si è stabilito se le API di questo pacchetto sono una sola API che contiene diversi endpoint e so invece ciascun endpoint e' una API a se stante?

Esposizione dei servizi di interoperabilità tra protocolli informatici

Premessa

Il CAD, art. 6-ter impone l’obbligo di aggiornamento dell’Indice dei domicili digitali delle pubbliche amministrazioni e dei gestori di pubblici servizi
Dalle LLGG documento informatico: Allegato 6 – Cap. 3:

Per dare seguito alla comunicazione tra AOO mittente e AOO destinataria, le stesse adottano la modalità previste dalla norma basata sulla cooperazione applicativa, utilizzando il Simple Object Access Protocol assicurando l’implementazione delle interfacce di servizio riportate nell’Appendice B.
Per assicurare la comunicazione tra AOO le Amministrazioni DEVONO registrare e mantenere aggiornato, per ogni AOO individuata nella propria organizzazione, l’Indice dei domicili digitali delle pubbliche amministrazioni e dei gestori di pubblici servizi (IPA) con il prefisso condiviso dagli endpoint di esposizione dei servizi indicati nell’Appendice B.

Situazione attuale di IndicePA

Su IndicePA nei metadati delle Aree Organizzative Omogenee (AOO) si legge:

"COLUMN_NAME": "Protocollo_informatico"
"COLUMN_COMMENT": "Flag che indica la presenza/assenza di un protocollo informatico (valori S/N/null)"
"COLUMN_NAME": "URI_Protocollo_informatico"
"COLUMN_COMMENT": "URI del protocollo informatico in caso di sua presenza"

Analizzando il dataset delle AOO si ottengono i seguenti risultati:

1. Su 37.715 AOO censite:

• 3.643 dichiarano di non avere il protocollo informatico (sic!)
• 479 dichiarano di avere il protocollo informatico
• 33.593 lasciano il campo vuoto

2. Delle 479 AOO che dichiarano di avere il protocollo informatico:

• 478 compilano il campo URI_Protocollo_informatico

3. Analizzando i 478 valori del campo URI_Protocollo_informatico si individuano le seguenti casistiche:

• 251 sono indirizzi e-mail
• 107 sono url del sito web dell’ente
• 93 sono url dell’accesso web (si presume alla consultazione)
• 27 sono privi di senso

Considerazioni

Vincoli

1. Le Pubbliche Amministrazioni DEVONO adottare il protocollo informatico (dal 2015)
2. Il sistema di protocollo informatico DEVE esporre le interfacce di servizio definite dalle LLGG
3. Gli endpoint delle interfacce di servizio DEVONO essere pubblicati e mantenuti aggiornati su IndicePA

Osservazioni

1. Le Linee guida dovrebbero chiarire, anche con esempi, come devono essere compilati i campi Protocollo_informatico e URI_Protocollo_informatico su IndicePA.
2. IndicePA dovrebbe:

• rendere obbligatoria la compilazione dei campi Protocollo_informatico e URI_Protocollo_informatico al momento del popolamento/aggiornamento dei dati della AOO
• validare formalmente gli indirizzi degli endpoint
• verificare che i servizi rispondano alle chiamate (SOAP/REST)

3. Non è pensabile che i servizi di interoperabilità tra i protocolli informatici siano esposti sulla PDND per i seguenti motivi:

• I servizi di interoperabilità tra i protocolli informatici devono (per loro natura) essere pubblici
• La registrazione delle 37.715 AOO della PA come erogatori e fruitori di servizi su PDND comporterebbe 1.422.421.225 accordi di fruizione

Errore in fase di validazione con il vecchio "segnatura.xsd" del 2013 fallisce con i vecchi xml sempre del 2013

Stiamo lavorando per aggiornare il protocollo alla nuova versione, ma non riusciamo a effettuare la validazione dei vecchi xml perchè con il vecchio xsd https://github.com/AgID/protocollo-comunicazione-aoo/blob/master/previous_schemas/segnatura_protocollo_circolare%2060_2013.xsd ci fallisce la validazione sul campo "versione" con l'errore: cvc-complex-type.3.1: Value '2013-01-23' of attribute 'versione' of element 'Segnatura' is not valid with respect to the corresponding attribute use. Attribute 'versione' has a fixed value of 'aaaa-mm-gg'. per far passare il controllo dobbiamo mettere la strigna "aaaa-mm-gg" che è sbagliato.

Potete chiarire la problematica?

Alleghiamo il file xml di test e lo mettiamo in chiaro in questo ticket.
esempio_segnatura_xml_2013.xml.txt

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Segnatura xmlns="http://www.digitPa.gov.it/protocollo/" versione="2013-01-23" xml-lang="it">
  <Intestazione>
    <Identificatore>
      <CodiceAmministrazione>codice_ente</CodiceAmministrazione>
      <CodiceAOO>codice_ente</CodiceAOO>
      <CodiceRegistro>protocollo-generale</CodiceRegistro>
      <NumeroRegistrazione>0000021</NumeroRegistrazione>
      <DataRegistrazione>2024-03-06</DataRegistrazione>
    </Identificatore>
    <OraRegistrazione tempo="spc">17:33:14</OraRegistrazione>
    <Origine>
      <IndirizzoTelematico tipo="smtp">[email protected]</IndirizzoTelematico>
      <Mittente>
        <Amministrazione>
          <Denominazione>Test Ente</Denominazione>
          <UnitaOrganizzativa tipo="permanente">
            <Denominazione>Test Ente</Denominazione>
            <IndirizzoPostale>
              <Indirizzo>
                <Toponimo>XXX</Toponimo>
                <Civico>XXX</Civico>
                <CAP>XXX</CAP>
                <Comune>XXX</Comune>
                <Provincia>XXX</Provincia>
              </Indirizzo>
            </IndirizzoPostale>
          </UnitaOrganizzativa>
        </Amministrazione>
        <AOO>
          <Denominazione>Test Ente</Denominazione>
        </AOO>
      </Mittente>
    </Origine>
    <Destinazione confermaRicezione="no">
      <IndirizzoTelematico tipo="smtp">[email protected]</IndirizzoTelematico>
      <Destinatario>
        <Persona>
          <Nome>Mario</Nome>
          <Cognome>Rossi</Cognome>
          <CodiceFiscale/>
        </Persona>
        <IndirizzoPostale>
          <Denominazione>,  </Denominazione>
        </IndirizzoPostale>
      </Destinatario>
    </Destinazione>
    <Oggetto>test</Oggetto>
  </Intestazione>
  <Descrizione>
    <Documento nome="nomeFile.xml" tipoMIME="text/xml" tipoRiferimento="MIME">
      <TipoDocumento>Documento Principale</TipoDocumento>
      <Oggetto>Registro giornaliero repertorio-generale XXX</Oggetto>
      <PiuInfo XMLSchema="improntaPiuInfo.xsd">
        <MetadatiInterni>YYY</MetadatiInterni>
      </PiuInfo>
    </Documento>
  </Descrizione>
</Segnatura>

Dubbio invio conferma in caso di anomalia

Salve,
avrei bisogno di qualche chiarimento relativamente all'invio della conferma e in particolare quando il destinatario deve segnalare un'anomalia. Il WSDL prevede che per il metodo ConfermaMessaggioInoltro si debba restituire l'identificatore del mittente e, nel caso di anomalia, il parametro Anomalia di tipo AnomalieConfermaType.
Nell'ipotesi di avere un mittente che invia ad un destinatario, il discorso è chiaro e non ci sono problemi. I miei dubbi nascono nel caso in cui un mittenti invii a più destinatari e successivamente riceva delle anomalie. Chiaramente nella situazione ideale se il messaggio inviato ha qualche errore, tutti i destinatari dovrebbero inviare la medesima anomalia.
Però nella realtà ci sono sistemi diversi, implementati in modo diverso ed è possibile che solo alcuni destinatari restituiscano l'anomalia (è già capitato in passato che qualche sistema non riconoscesse come valide delle segnature corrette).
In questi casi, dato che la comunicazione della conferma è ascinrona, il mittente si troverebbe con diverse chiamate al metodo ConfermaMessaggioInoltro, ma non riuscirebbe a capire da chi arriva una certa anomalia perchè il metodo consente solo di specificare l'identificatore del mittente e l'anomalia. Nell'oggetto AnomalieConfermaType però non c'e' la possibilità di specificare il codice IPA del destinatario che sta inviando il messaggio e quindi il risultato è che il mittente riceve N anomalie, ma non sa da chi sono state inviate.
Se invece le conferme arrivano correttamente, allora al posto dell'anomalia il mittente riceve l'identificatore del destinatario e quindi riesce a capire da chi arriva il messaggio.

Come va gestita questa situazione? E' prevista qualche modifica in questo metodo?

Segnatura, sigillo e invio tramite web service

Salve,
avrei dei dubbi sulla generazione della segnatura, sull'applicazione del sigillo e sul successivo invio tramite web service.
La generazione della segnatura in base alle specifiche dell'XSD e l'applicazione del sigillo non sono un problema. Ottengo una cosa di questo tipo:

<?xml version="1.0" encoding="utf-8"?>
<prot:SegnaturaInformatica xmlns:prot="http://www.agid.gov.it/protocollo/" prot:versione="3.0.0" prot:lang="it">
  <prot:Intestazione>
    <prot:Identificatore>
     ....
    </prot:Identificatore>
    <prot:Oggetto>Oggetto</prot:Oggetto>
    <prot:Classifica>
      ....
    </prot:Classifica>
  </prot:Intestazione>
  <prot:Descrizione>
    <prot:Mittente>
      ...
    </prot:Mittente>
    <prot:Destinatario>
      ...
    </prot:Destinatario>
    <prot:DocumentoPrimario prot:nomeFile="DOCUMENTO" prot:mimeType="application/pdf">
      ...
    </prot:DocumentoPrimario>
  </prot:Descrizione><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-334305326">
	....
</ds:Signature>
</prot:SegnaturaInformatica>

La successiva validazione tramite XSD va a buon fine e anche la validazione del sigillo viene verificata senza errori.
Quello che mi risulta problematico è l'invio tramite web service. In modo particolare analizzando il WSDL quello che vedo è che il messaggio SOAP relativo alla richiesta di inoltro dovrebbe essere una cosa di questo tipo:

<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Header>
    <a:Action s:mustUnderstand="1">http://tempuri.org/IProtocolloDestinatario/MessaggioInoltro</a:Action>
    <a:MessageID>urn:uuid:9247cadd-5334-4fb0-ae0c-e78f16dd29ce</a:MessageID>
    <a:ReplyTo>
      <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
    </a:ReplyTo>
  </s:Header>
  <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <MessaggioInoltro xmlns="http://tempuri.org/">
      <Segnatura xmlns:prot="http://www.agid.gov.it/protocollo/" prot:versione="3.0.0" prot:lang="it">
                <prot:Intestazione>
		  .....
		 </prot:Intestazione>
 		  .....
		  <ds:Signature Id="ID" xmlns="http://www.w3.org/2000/09/xmldsig#">
		  .....
		  </ds:Signature>
	  </Segnatura>
      <files>
        <FileType nomeFile="FILE1">CONTENT</FileType>
      </files>
    </MessaggioInoltro>
  </s:Body>
</s:Envelope>

L'elemento Segnatura è di tipo SegnaturaInformaticaType e quindi è dello stesso tipo che ho utilizzato per la generazione della segnatura del mittente. Il problema è che il nodo root risultante viene chiamato "Segnatura" e non "SegnaturaInformatica".
Quindi per generare un messaggio SOAP di questo tipo devo prendere la segnatura originale e cambiare il nome del nodo root. Questa modifica però implica che il sigillo non sarà più valido e devo applicarne un altro.
Anche se applicassi un nuovo sigillo, in ogni caso il destinatario riceverebbe una segnatura diversa rispetto a quella del mittente.

In conclusione quello che mi chiedo è:

1. Non sarebbe meglio passare la segnatura come FileType come si per gli altri allegati? Sarebbe un po' tornare alla situazione delle email in cui la segnatura è un semplice allegato di una email, che poi dovrà avere una certa struttura definita dall'apposito XSD.
2. Nel caso in cui non sia possibile il discorso del FileType, non sarebbe almeno possibile allineare i nomi degli elementi della segnatura?

Sto sbagliando qualcosa su quanto ho detto in precedenza?

Dubbi su Appendice C, Comunicazione tra AOO di Documenti Amministrativi Protocollati

Salve,

nell'Appendice C del documento in oggetto si fa riferimento ai nomi dei file degli allegati delle mail interoperabili (es.: Segnatura.xml, Aggiornamento.xml, etc.). I nomi dei file indicati hanno un carattere di obbligatorietà, o quella è solo un'indicazione facoltativa? Quello che fa fede, quindi, per riconoscere la tipologia del messaggio interoperabile è sempre la l'elemento root dell'xml, o si può fare affidamento anche al nome dell'allegato? Ad esempio, è consentito che l'allegato di segnatura si possa chiamare SegnaturaInformatica.xml (o in altro modo) invece di Segnatura.xml?

Grazie

Chiarimenti su applicazione linee guida in materia di interoperabilità

Comunicazione tramite PEC : Messaggi di ritorno
Vi chiediamo conferma che, in caso di utilizzo delle PEC come canale di comunicazione, i messaggi di ritorno rimangano invariati nelle caratteristiche di gestione e che pertanto le specifiche individuate nel paragrafo 3.1 dell'allegato 6 (Regole di processamento) siano da gestire al momento dell'utilizzo dei web services come canale di comunicazione (o comunque non siano da intendersi come adeguamenti vincolanti in caso di utilizzo delle PEC come canale di interoperabilità).

Comunicazione tramite web services : ricevute con valore legale"
Nello scenario di scambio di messaggi tra AOO tramite WebService (SOAP) si rileva la necessità di restituire al mittente (sistema chiamante) una ricevuta con valore legale dell’avvenuta consegna.

Messaggi di grande dimensione

Buongiorno,
come p.a., il Comune di rivoli rappresenta un caso concreto e quotidiano.
Invio di una comunicazione protocollata con queste caratteristiche:

• 31 allegati;
• dimensione complessiva 105MB
• 18 destinatari fra cui: 10 p.a., 5 grandi società, 1 società partecipata, 2 professionisti (privati).

Nello specifico si tratta di una comunicazione riguardante un "piano esecutivo convenzionato" che per sua natura riguarda più soggetti di varia natura e lo scambio di elaborati e progetti di dimensioni elevate e in quantità elevata.

Riallacciandoci a varie issue aperte, non ci sembra di vedere nelle nuove linee guida una soluzione univoca a questa esigenza, sicuramente comune a qualsiasi p.a.

Al momento tutte le soluzioni che si possono mettere in campo sono soluzioni particolari, spesso di compromesso e in deroga alla normativa e alle buone pratiche archivistiche, e soprattutto non condivise da tutte le p.a. e non esperibili verso società o professionisti privati Fra queste:

• suddivisione della comunicazione in più invii PEC e quindi in più registrazioni di protocollo: errore archivistico e aggravio di procedura per mittente e destinatario;
• messa a disposizione dei file su server esterno eventualmente protetto da password: altro errore archivistico perche' il protocollo del mittente non acquisisce i documenti e chi riceve non ha garanzia sulla immodificabilità / non sostituzione del file. onerosità e rischio per la sicurezza per il destinatario,
  con eventuali varianti sul tema.

Nel caso specifico, avendo il Comune messo a disposizione i file su un proprio server, un ente pubblico ha rifiutato la comunicazione rispondendo nel seguente, condivisibile, modo: "per ragioni di sicurezza e ai fini della conservazione agli atti dell'archivio della documentazione inviata, ci vediamo costretti a non accettare la ricezione di documenti salvai su server esterni. Gli allegati devono essere inseriti fisicamente nella PEC".

Come accennato, nemmeno le nuove linee guida consentono l'individuazione di una modalità unica e condivisa per lo scambio di messaggi voluminosi. Se l'ipotesi WS SOAP potrebbe - nn in tempi brevi - risolvere la questione per comunicazioni fra AOO, il problema resta immutato per destinatari di altra natura giuridica che, come nel caso concreto descritto, possono essere destinatari di una comunicazione inviata anche a p.a.

La mancanza di una modalità unica per gestire queste situazioni rende di fatto impossibile la realizzazione di qualsiasi strumento per automatizzare l'invio di comunicazione voluminose: potremmo chiedere alla software house che ci fornisce il protocollo informatico una modifica che soddisfi le nostre esigenze di mittente ma che potrebbe continuare a produrre comunicazioni che un destinatario può rifiutare o non essere in grado di interpretare. Nel verso opposto, quando siamo destinatari, non possiamo far implementare alcun meccanismo per interpretare invii voluminosi, perché non esiste un modo unico.

Forse i tempi sono maturi per una soluzione unica e condivisa, che guardi anche al di là del panorama AOO?

Rapporto tra data di apposizione del sigillo sul file Segnatura.xml e data di protocollo

Buongiorno,
tra i controlli che abbiamo implementato nel nostro modulo di ricezione messaggi di protocollo verifichiamo che, se è presente il sigillo nel file Segnatura.xml, la data di apposizione del sigillo coincida con la data di protocollazione dichiarata nel file Segnatura.xml nel tag "DataRegistrazione" altrimenti si effettua un rifiuto automatico con codice "001_ValidazioneFirma". Questa interpretazione è troppo stringente oppure è corretta sulla base di quanto indicato nell'Allegato 6 con riferimento al paragrafo "2.2 Regole di processamento" in quanto riceviamo da alcune ASL dei file di Segnatura sigillati posteriormente alla data di creazione della registrazione di protocollo.

Chiarimenti su comunicazioni PEC e WS

Recepita la finalità delle linee guida di individuare la modalità di comunicazione tramite posta elettronica certificata (PEC) come residuale, in attesa che tutte le AOO provvedano ad attrezzarsi con gli opportuni strumenti per l’utilizzo dei WS REST, si richiedono approfondimenti in merito alla gestione di situazioni "miste"

Individuazione delle AOO a cui prevedere la comunicazione tramite WS REST

La presenza in IPA degli endpoint ("URI_Protocollo_informatico") sia dell'AOO mittente che dell'AOO destinataria rappresenta la condizione di obbligatorietà di comunicazione tramite WS REST ?
Per tali comunicazioni esiste un vincolo di ricevere la risposta tramite il medesimo canale oppure se viene ammessa la possibilità di inviare le conferme, etc. tramite il canale della PEC ?

Gestione di spedizione del medesimo messaggio sia tramite WS che tramite PEC

Dal momento la comunicazione tramite il canale PEC (REM) dovrà essere comunque mantenuta per l'invio a cittadini/imprese ed AOO non predisposte alla ricezione tramite WS, gli Enti si troveranno nella condizione di gestire la spedizione della medesima comunicazione a destinatari diversi in modalità differenti.
In questo caso si andrebbe a creare una difformità nella gestione del medesimo messaggio e delle informazioni sulle relative ricevute e la richiesta è pertanto se in questi casi è il sistema di protocollo mittente che deve uniformare il canale di comunicazione (in alternativa se sono state approfondite delle modalità organizzative da condividere con gli Enti per la gestione di queste casistiche).

Valore legale delle ricevute prodotte a seguito di comunicazioni via WS.
Le ricevute PEC hanno pieno valore legale e sono opponibili a terzi, perché prodotte da un soggetto appositamente autorizzato.
La richiesta è la certificazione delle medesime garanzie rappresentate delle ricevute WS.

Disservizi nel flusso di comunicazione tramite WS
Qualora l’AOO Mittente riscontri la presenza di disservizi nel flusso di comunicazione tramite WS (presumibilmente imputabili all’AOO Destinataria) è plausibile procedere con la comunicazione tramite PEC ?
Il riferimento è relativo all'utilizzo di canali alternativi per superare o evidenziare problemi di comunicazione.

Approfitto infine di questo canale per richiedere la possibilità di un approfondimento sulla tematica di passaggio da PEC a REM e sui relativi impatti con la gestione dei messaggi nei sistemi di protocollo; le REM prevedono infatti l'autenticazione a due livelli e vi chiedo pertanto se sono previste e consentite delle modalità di accesso automatico da parte di sistemi informatici per la gestione del protocollo.

Numero di mittenti nella segnatura di protocollo

Buongiorno,
nell'XSD della segnature di protocollo è previsto 1 solo mittente.
Se ne inserisco più di uno la segnatura non viene validata.

Non si potrebbe adeguare l'XSD per prevedere quello che è un caso frequente?

URL/URI dei namespace

Salve, nella definizione dei namespace (o come si vogliano chiamare i riferimenti a schemi XSD esterni) non potrebbe essere utile il puntamento all'xsd a cui ci si riferisce piuttosto che a degli indirizzi web che danno errore 404?
Forse, dico forse, aiuterebbe la validazione degli XML anche ai meno esperti.

Es.:
xmlns:msgprot="http://www.agid.gov.it/protocollo/messaggi/"
xmlns:prot="http://www.agid.gov.it/protocollo/"
targetNamespace="http://www.agid.gov.it/protocollo/messaggi/"

Data del sigillo e data del protocollo: richiesta di renderle indipendenti

Da specifiche la data del sigillo deve coincidere con la data di protocollo, pena l'irregolarità della segnatura o lo scarto totale del messaggio. Infatti il paragrafo 2.2 richiede di creare la segnatura sigillata al momento della registrazione del documento.

Suggerisco di rimuovere questa indicazione per i seguenti motivi (e ce ne sono altri):

• la segnatura accompagna il documento nel suo viaggio da una AOO all'altra ed è quindi legata al momento del trasferimento del documento non alla sua registrazione (quelli sono i metadati dell'allegato 5);
• nella maggioranza dei casi le due operazioni sono contestuali ma esistono casi del tutto legittimi e leciti in cui ciò può avvenire in momenti distinti. Per esempio: caso della casella destinataria non disponibile.
• la norma inoltre consente la modifica di alcuni dati di registrazione a patto di tenerne traccia, se la segnatura è creata e sigillata contestualmente alla registrazione a protocollo diventa immodificabile e non può accogliere le modifiche.

Le segnatura dovrebbe invece crearsi al momento della spedizione del messaggio ed essere un elemento della spedizione non della registrazione di protocollo.

Allegato 6: dubbi emersi in fase di analisi delle nuove linee guida 2

1) Endpoint su IPA a livello di AOO, mentre le PEC sembrano anche a livello di settore
Alcuni Enti hanno una struttura molto articolata di AOO e Settori sottostanti.
Prendiamo ad esempio Regione Piemonte con la AOO A1000A - DIREZIONE DELLA GIUNTA REGIONALE.
Tale AOO ha la sua PEC [email protected] .
In questo momento però le trasmissioni di protocollo non sempre vengono inviate alla PEC dell'AOO, ma alle PEC del settore sottostante (ad es. [email protected]).
Se abbiamo inteso correttamente l'allegato, in futuro tutto arriverà ad un unico endpoint della AOO. Come va interpretato il processo di smistamento sul settore? Potrebbe essere un valore contenuto nel messaggio stesso ad indicare il settore?

2) Il nuovo protocollo di comunicazione tra AOO via web services prevede il riconoscimento delle due controparti: entrambe dovranno pubblicare il loro endpoint su IPA.
Nel processo attuale, con la PEC, due AOO che devono scambiarsi un documento non devono stipulare alcun accordo formale. Con la PEC non è previsto un riconoscimento delle due parti precedente allo scambio. Nel momento in cui si deve inviare un documento protocollato ad una AOO mai contattata in precedenza, viene indicato il suo indirizzo PEC.
Con il nuovo interscambio invece si prevede una sorta di accordo formale e di registrazione delle chiavi pubbliche del certificato affinché le due parti possano “colloquiare”:
L’instaurazione del canale dovrà essere fatta a seguito di una mutua autenticazione attraverso l’uso di certificati X509 V3 (tipicamente attraverso la verifica del campo subject DN dello stesso certificato). Le amministrazioni dovranno dotarsi dei certificati autonomamente
Dal punto di vista organizzativo questa nuova condizione potrebbe costituire uno scoglio. Come potrebbe essere mitigato l’impatto sull’Ente?

3) La Segnatura dovrà essere firmata attraverso Sigillo Elettronico qualificato (sia via PEC che sul canale WS-SOAP): se tale Sigillo fosse scaduto quando effettuo la verifica?
Se il Sigillo che garantisce l’integrità fosse valido nel momento in cui lo appongo (supponiamo in data odierna avvenga la protocollazione in uscita) ma l’AOO ricevente dovesse protocollare in ingresso tra un mese, quel Sigillo potrebbe non essere più valido.
Cosa posso fare al fine di non far scadere il Sigillo elettronico qualificato della mia AOO?
Nelle specifiche non abbiamo trovato riferimenti al momento in cui vada verificata la validità del sigillo sulla Segnatura. Crediamo sia da intendersi all'apposizione della stessa. Si parla genericamente di errore "001_ValidazioneFirma".
Dai wsdl vediamo che tale validazione è nella ResponseMessaggioInoltro, quindi sembrerebbe da intender-si valida alla data della trasmissione, non necessariamente a quella della protocollazione in ingresso a seguito della quale viene inviata la conferma. Se la trasmissione non fosse contestuale alla protocollazione in uscita (oggi protocollo e domani invio la segnatura, magari per tempi tecnici dell'ente) potrei comunque inviare una Segnatura con un Sigillo scaduto. Quali tipi di controlli dovrei applicare?
Quella degli allegati invece viene verificata in fase di conferma (006_DocumentoAllegatiErroreValidazioneSigillo) e a quel punto, il Sigillo potrebbe essere scaduto.

4) Cosa significa l'errore "000_Irricevibilita"?
Si tratta di un errore per processo interno dell'Ente? Un funzionario, dopo che il messaggio è arrivato correttamente ed ha passato i controlli formali, entra nel merito per protocollarlo e si accorge ad esempio che un allegato è in formato zip. Anche se tale formato è ammesso, il suo ufficio accetta solo pdf, quindi a quel punto rifiuta per irricevibilità e specifica di ritrasmettere il messaggio con il formato richiesto dal suo standard interno. È corretta questa interpretazione? L'errore di irricevibilità ci sembra avvenga dopo una serie di altri controlli.

5) Può verificarsi il caso in cui l’invio della Segnatura avvenga su canale a servizi e la conferma arrivi invece via PEC (o viceversa)?
La nostra AOO effettuerà una serie di tentativi di invio a servizi e poi, non riuscendoci, cambierà canale di trasmissione passando alla PEC per indisponibilità del primo. Il ricevente successivamente prova a contattarmi per la conferma e riesce a farlo sul canale prioritario. Oppure succede l’esatto opposto. La conferma potrebbe avvenire anche molto tempo dopo la trasmissione di protocollo (dalla documentazione si evince che il messaggio di conferma viene inviato solo quando l'AOO ricevente protocolla in ingresso).
Si può verificare questa condizione? I sistemi di invio e ricezione sono separati, potrebbe non essere raggiungibile uno mentre l’altro si. Deve essere fatto un controllo sul canale di trasmissione? Se ricevo il messaggio inoltro a servizi devo trasmettere necessariamente la conferma di ricezione del messaggio a servizi?

Proposta per verifica stato di adeguamento alla nuova segnatura

Salve, a un certo numero di mesi dall'obbligo di usare la nuova segnatura XML sigillata, dal piccolo punto di osservazione del mio ente ci sembra che permangano molti (la maggioranza?) casi di segnature non adeguate, vuoi perché non sigillate, vuoi perché mal formate.
Per un ente singolo si tratta di scegliere fra notificare eccezioni a tappeto con rischio di paralisi delle attività, gestione di invii ripetuti (non risolutivi dei problemi) che poi devono essere accettati per sfinimento e individuare delle vie di mezzo che cerchino di conservare la validità delle comunicazioni nonostante la non conformità della segnatura.xml (lieve forzatura, visto che le linee guida direbbero di fare eccezione e stop).

Vengo alla proposta: AgID o chi per lei non potrebbe farsi carico di adottare una campagna di verifica dell'adeguamento alla nuova segnatura, invitando formalmente tutte le p.a. italiane a inviare una comunicazione di prova con determinate caratteristiche a una data AOO e implementare dei controlli automatici con riscontro da fornire al mittente?

PS: sarebbe anche un'attività propedeutica al passaggio da PEC a WS, sempre che non sia un'ipotesi di fatto accantonata... viene infatti da pensare che la comunicazione via WS richiede una correttezza formale di una comunicazione via PEC (che, di fatto, funziona anche senza segnatura).