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.
[…]
Continua a leggere l’Allegato 2 sul sito AgID
Capitolo 3.1.1 Ciclo di vita
Il punto “ARCHIVIA MANUALMENTE, da SOSPESO: l’Erogatore archivia manualmente la versione attualmente sospesa dell’e-service;” non è coerente con quanto riportato sia nel diagramma di flusso che nel capitolo 3.1 il quale riporta che “L’Erogatore PUÒ archiviare manualmente una versione deprecata di un e-service.” La frase dovrebbe quindi essere “ARCHIVIA MANUALMENTE, da DEPRECATO: l’Erogatore archivia manualmente la versione attualmente deprecata dell’e-service;”
Capitolo 3.1.2 Data model
In tabella viene riportato il campo data revoca come data della revoca dell’e-service (come riportato nella colonna “Descrizione”). Nella colonna “Modificabile” viene riportato che questo attributo viene valorizzato all’esecuzione della transazione di stato REVOCA. Lo stato REVOCATO non è più presente in queste linee guida e sembra essere stato sostituito dallo stato DEPRECATO. Si suggerisce quindi di modificare il campo data revoca con data depreca e di modificare la dicitura nella colonna “Modificabile” con “NO l’attributo è valorizzato una sola volta all’esecuzione della transazione di stato DEPRECA dall’Infrastruttura Interoperabilità PDND”.
Capitolo 4 Fruizione degli e-service
Paragrafo:
L’Infrastruttura Interoperabilità PDND mette a disposizione dell’Erogatore, in via facoltativa, un meccanismo di approvazione automatica delle richieste di fruizione per un e-service. L’approvazione automatica è vincolata al soddisfacimento dei requisiti di fruizione con riferimento agli attributi certificati e dichiarati di cui l’Aderente che invia la richiesta di fruizione è in possesso.
Non è chiaro se, qualora vi siano attributi verificati, sia possibile impostare il meccanismo di approvazione automatica delle richieste di fruizione per un e-service. In caso contrario si suggerisce di esplicitare l’impossibilità di impostare il meccanismo di approvazione automatica qualora l’e-service richieda la presenza di attributi verificati. Rispetto alle linee guida precedenti in cui si precisava quanto segue:
un Erogatore PUÒ ritenere valida - assumendosene la responsabilità - la verifica di un attributo effettuata da altro Erogatore, in considerazione della natura di quest’ultimo, nonché delle caratteristiche anche temporali dell’attributo;
è stata rimossa la possibilità di avvalersi della verifica effettuata precedentemente dall’Aderente stesso o da altri Erogatori? Se ciò fosse ancora valido, si potrebbe prevedere un meccanismo automatico. Nel caso contrario, ovvero che vadano verificati manualmente ogni volta gli attributi, il meccanismo di approvazione automatica non dovrà essere disponibile.
Paragrafo 3.1.2. Data model
Tabella con riportati i dati minimi dell’entità Interfaccia.
idl specifica dell’interfaccia legata alla versione dell’e-service dovrebbe essere obbligatorio SI e modificabile NO
Paragrafo 3.1.2. Data model
In considerazione del fatto che le specifiche dell’interfaccia (OpenAPI o WSDL) potrebbero non essere autoesplicative, si propone di rendere obbligatoria la pubblicazione di documentazione accessoria e manualistica per l’utilizzo dell’interfaccia.
La documentazione dovrebbe essere obbligatoria soprattutto se le risposte del servizio hanno struttura articolata
Capitolo 4. Fruizione degli e-service
L’Infrastruttura Interoperabilità PDND, completate le azioni da parte del Fruitore, DEVE comunicare le informazioni registrate da questi all’Erogatore dell’e-service nell’ipotesi in cui la stima di carico relativa alla specifica finalità richiesta del Fruitore ecceda la disponibilità precedentemente dichiarata dall’Erogatore.