Convenzioni e granularità di accreditamento

[cloudify]

Apro una issue per discutere su un tema pratico, legato all'interoperabilità tra i sistemi.

Attualmente se PA_A vuole usare dal suo servizio SA_1 un servizio SB_1 fornito da PA_B, accade che:

1. PA_A e PA_B firmano una convenzione
2. PA_B espone via porta di dominio il proprio servizio SB_1 nella rete di PA_A (configurando la porta di dominio con un certificato fornito da AgID)
3. SA_1 può chiamare SB_1 tramite la porta di dominio
4. eventualmente un altro servizio SA_2 puo' usare la stessa porta di dominio per chiamare SB_1 senza che PA si ri-accrediti

Ora, tra le varie problematiche di questo modello, c'è quella che riguarda la granularità di autenticazione (a livello di PA), mentre sarebbe opportuno avere un'autenticazione a livello di servizi (es. SA_1), in modo che le chiavi o i certificati di autenticazione di SA_1 e SA_2 possano essere gestiti indipendentemente e che SB_1 possa associare a SA_1 ed SA_2 livelli di servizio o restrizioni differenti (addirittura disattivare l'accesso ad un solo servizio in caso di abuso).

Tecnicamente è chiaro come gestire l'autenticazione a livello di servizio nel nuovo modello di interoperabilità ma non è molto chiaro come venga gestito l'accreditamento a livello di contratto e di convenzione.

Per esempio, nel caso di un ente A che si appoggia ad una software house (o in-house) B per integrare un servizio fornito dall'ente C:

• chi stipula la convezione? (immagino A e C)
• cosa succede nello scenario in cui A è un ente molto grande (es una regione) composta da vari dipartimenti con una loro autonomia? vengono stipulate più convenzioni?
• dopo aver stipulato una convenzione, in caso ci si debba accreditare al servizio fornito da C tramite un developer portal, chi ha la responsabilità di fare l'accreditamento? (es. B? o un funzionario di A? se un funzionario di A, che tipo di funzionario? per dipartimento?)
• in caso il servizio fornito da C abbia un costo periodico (es. acquisto di credito per l'invio di SMS), come avverrebbe il pagamento?

Sarebbe molto utile avere una linea guida che spieghi tutti questi passi in un modello di riferimento.

[spiunno]

Il nuovo modello propone uno schema che è più granulare in termini di controllo di accesso e meno granulare in termini di convenzioni. In particolare nell'esempio citato le chiavi e i certificati relativi a SA_1, SA2 sarebbero diversi. La generazione delle chiavi e dei certificati sarà automatizzata per agevolare la maggiore granularità.

Viceversa, al livello di convenzioni nel nuovo schema tutte le amministrazioni partecipanti firmano una unica convenzione tra loro e AgID e così facendo accettano le regole di funzionamento del circuito e si predispongono (da un punto di vista legale) alla cooperazione applicativa con tutti gli altri enti partecipanti.

Nell'esempio sia A che C hanno firmato una convenzione con AgID. Nessuna convenzione viene firmata tra A e C, nessuna convenzione viene firmata da B (che è un semplice fornitore di A) Una singola convenzione permette di attivare/disattivare molteplici canali di interazione con gli altri enti, quindi non c'è motivo di firmare una convenzione separata per ogni dipartimento, tuttavia a livello tecnologico sarà possibile per un ente molto grande separare le proprie API su multipli endpoint gestiti ognuno da un diverso dipartimento - questo fa parte della gestione interna e non interessa gli altri enti. Non ci sono al momento regole su chi, all'interno di un ente, debba avere la responsabilità dell'accreditamento sul catalogo/marketplace. Un buon default sembrerebbe essere il responsabile della trasformazione digitale (art 17 CAD) Non ci sono al momento regole sul ribaltamento dei costi. L'orientamento prevalente nelle discussioni su questo tema è stato fino ad ora che l'accesso ad API tra Pubbliche Amministrazioni non dovrebbe comportare corrispettivi economici in quanto fornire il servizio, ancorchè via API, fa parte delle finalità istituzionali dell'ente erogatore.