Comments (6)
Sono del parere che si lascia il governo della interoperabilità legato a dei campi compilati in IPA dalle singole amministrazioni senza un controllo massivo e automatico di validazione si generi semplicemente una metodologia che non sarà utilizzata a causa dei troppi errori in invio che poterà le amministrazioni a utilizzare il vecchio (nuovo) sistema di interoperabilità via REM. Sono quindi due le strade possibili:
- si validano i dati presenti in IPA e si tengono monitorati i servizi di interoperabilità e i solo SLA
- si lavora su una parte del PDND gestita centralmente che riconosce gli end point delle singole amministrazioni, ed essendo un canale qualificato potrebbe non richiedere la firma Xades della segnatura.
Non mi è chiaro perchè si afferma che il servizio di interoperabilità tra AOO debba essere pubblico. Anzi deve essere un canale sicuro, affidabile e certo. Quanti attacchi di sicurezza si potrebbero fare agli end point pubblici di interoperabilità tra AOO ?
from protocollo-comunicazione-aoo.
L'obbligo di utilizzo del protocollo informatico è sancito dal'art. 50 del TUDA
L'obbligo della pubblicazione su IPA è definito dall'art. 6-ter del CAD
Al fine di assicurare la pubblicità dei riferimenti telematici delle pubbliche amministrazioni e dei gestori dei pubblici servizi è istituito il pubblico elenco di fiducia denominato "Indice dei domicili digitali della pubblica amministrazione e dei gestori di pubblici servizi", nel quale sono indicati i domicili digitali da utilizzare per le comunicazioni e per lo scambio di informazioni e per l'invio di documenti a tutti gli effetti di legge tra le pubbliche amministrazioni, i gestori di pubblici servizi e i privati.
e nell'allegato 6 alle LGG del documento informatico:
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.
È certo che, sulla base delle prescrizioni normative, i campi previsti da IPA devono essere modificati rendendo obbligatorio l'inserimento degli endpoint e la loro validazione. Ricordo che il mancato popolamento dell'IPA è sanzionato (CAD, at 6-ter)
La mancata comunicazione degli elementi necessari al completamento dell'Indice e del loro aggiornamento è valutata ai fini della responsabilità dirigenziale e dell'attribuzione della retribuzione di risultato ai dirigenti responsabili.
Il servizio di interoperabilità deve essere pubblico perché così come una PA può inviare un messaggio a un'altra PA ottenendo la PEC/REM della AOO da IndicePA senza bisogno di registrazione, lo stesso deve poter fare con il canale Webservices (SOAP/REST)
La firma della segnatura serve a garantire l'immodificabilità di tutti documenti trasmessi, dal momento che nella segnatura sono inserite le impronte.
Gli attacchi di sicurezza si possono impedire utilizzando gli endpoint mittenti censiti su IPA come whitelist.
from protocollo-comunicazione-aoo.
La mia proposta è che l'allegato 6 e la realizzazione dell'interoperabilità su canale telematico deve avvenire per mezzo della integrazione della PDND e non con una modalità punto - punto su "url pubbliche" utilizzabili anche non da AOO.
Quindi i recapiti messi nell'IPA relativi alla interoperabilità di protocollo tra AOO (quindi tra soggetti pubblici) sarebbero già popolati con automatismi legati all'attivazione dell'ente sulla PDND, nel rispetto delle prescrizioni normative citate e senza aggravi ulteriori in carico agli enti.
Il servizio di interoperabilità tra AOO è tra enti pubblici (AOO appunto) e non pubblico nel senso ampio. L'adozione della PDND sebbene non obbligatoria dal punto di vista normativo, è in forte espansione sia per le integrazioni SIUS che ANPR/INAD. Non ha quindi senso pensare ad ulteriori canali telematici.
La PDND già garantisce la individuazione sicura del mittente e destinatario del flusso e garantisce l'integrità dei dati trasmessi in modo interoperabile come avviene per le altre API della piattaforma e quindi la sua adozione ai fini della interoperabilità di protocollo semplifica la necessità di firma Xades della segnatura.
from protocollo-comunicazione-aoo.
Se la firma XAdES della segnatura si mantiene è più sostenibile gestire il documento mantenendoci associata provenienza certa e integrità. Altrimenti occorre mantenere le varie request e response, più onerose da validare e senza certificatori qualificati (o quasi).
Poi può essere anche una firma (sigillo) non qualificato basato su dati di firma e validazione rilasciati da AgID o chi per lei (come per le PEC).
Poi ci possono essere vari altri modi.
La gestiione degli endpoint, a mio modo di vedere, non può funzionare né col paradigma del client e-service PDND né con l'endpoint pubblicato su IPA accessibile a tutti. Ok l'URL su IPA (poi si esprimano gli esperti di cyber) ma con il sistema di autenticazione previsto dalla PDND: quello c'è, magari a qualcuno ne piacciono di più altri, ma c'è quello (il token) e usiamolo.
Secondo me, già scritto, serve un nodo centrale, esposto, unico, lui solo, come API su PDND. Il nodo conosce gli endpoint delle p.a. (anche presi da IPA, anzi meglio, evitiamo ulteriori iscrizioni a servizi). Con buona pace dei casi d'uso PDND/PNRR per i comuni e il business plan ipotizzato dai fornitori...
Infibe, non ho approfondito, ma non vedo motivo per cui una non-PA debba usare il protocollo interoperabile, soprattutto perché non ha un protocollo informatico...
from protocollo-comunicazione-aoo.
Personalmente non ho opposizioni a che i servizi siano raggiungibili dal PDND, ma occorre che si modifichi il meccanismo di sottoscrizione, è impensabile che una PA debba essere fruitore PDND per spedire un messaggio interoperabile.
Ho delle perplessità relativamente all'abbandono di IPA, perché l'obbligo di aggiornamento è normato nel CAD e sanzionato il mancato aggiornamento. Non essendo l'adesione alla PDND un obbligo sarà ancora più difficile indurre le PA a rispettare il vincolo.
Concordo con @franthemanIT circa la difficoltà di gestire i log di PDND come prova dell'invio. La norma sul protocollo (TUDA) specifica con chiarezza l'associazione della segnatura (finalmente firmata) con i documenti al momento della registrazione di protocollo
from protocollo-comunicazione-aoo.
Direi che ora questo tema è centrale oltre che esponenzialmente non gestibile.
from protocollo-comunicazione-aoo.
Related Issues (20)
- Link WebService su IndicePA HOT 1
- Casi di segnature ricevute senza dati obbligatori - impronta non corrispondente e ditte individuali HOT 1
- Rapporto tra data di apposizione del sigillo sul file Segnatura.xml e data di protocollo
- Servizio per validazione segnatura rispetto ai file inviati HOT 1
- URL/URI dei namespace HOT 1
- Proposta per verifica stato di adeguamento alla nuova segnatura
- Numero di mittenti nella segnatura di protocollo HOT 1
- Quesito su allegato 6 - memorizzazione della conferma di protocollazione del messaggio di protocollo nel registro di protocollo HOT 1
- Richiesta di intervento a salvaguardia delle comunicazione fra AOO
- Data del sigillo e data del protocollo: richiesta di renderle indipendenti
- mittente / destinatario HOT 2
- La segnatura XML HOT 1
- bearerAuth e PDND HOT 2
- NON TECNICO: proposta di intenti HOT 2
- Allegato 6 & PDND HOT 2
- Chiarimenti su comunicazioni PEC e WS HOT 1
- Segnatura.xml e protocollo REST
- Prospettive uso API via PDND HOT 2
- Errore in fase di validazione con il vecchio "segnatura.xsd" del 2013 fallisce con i vecchi xml sempre del 2013 HOT 14
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from protocollo-comunicazione-aoo.