Ogni accesso SPID lascia una traccia, ma non si tratta del classico login con nome utente e password che si fa su un sito qualsiasi. Dietro quel pulsante Entra con SPID si nasconde una vera e propria transazione federata, regolata da norme tecniche e giuridiche precise, dove più soggetti si scambiano messaggi firmati digitalmente per confermare chi sei, controllare il livello di sicurezza richiesto e darti il via libera al servizio.
L’infrastruttura poggia su un insieme di regole che arrivano dal Codice dell’Amministrazione Digitale, dal DPCM del 24 ottobre 2014, dai regolamenti AgID, dal GDPR, dal Codice Privacy e, guardando all’Europa, dal regolamento eIDAS. Il punto è che ogni autenticazione lascia tracce tecniche, però non tutte hanno lo stesso peso e soprattutto non tutti i soggetti vedono le stesse cose. SPID registra ciò che serve a dimostrare che un’autenticazione c’è stata, chi l’ha chiesta, verso quale servizio e con quale esito. Quello che fai dopo essere entrato nel portale, almeno dal lato dell’Identity Provider, resta fuori dal suo raggio visivo.
I tre attori in gioco e perché i log sono sparsi
Per capirci qualcosa bisogna partire dai ruoli. L’Identity Provider (IdP) è il gestore dell’identità digitale, il soggetto accreditato che ti ha riconosciuto, ti ha dato le credenziali e gestisce l’autenticazione. Il Service Provider (SP) è invece chi offre il servizio online, che sia una Pubblica Amministrazione, un portale sanitario, tributario o una società privata aderente. Il SP non ti autentica da solo, chiede all’IdP di confermare la tua identità. Poi c’è AgID, che regola, vigila e gestisce l’infrastruttura di fiducia, ma attenzione: non possiede una cronologia centralizzata di ogni singolo accesso di ogni cittadino.
Il sistema è federato, e questo cambia tutto. Quando si apre il sito di un ente e si seleziona Entra con SPID, il SP genera una richiesta di autenticazione e la spedisce all’IdP. Quest’ultimo verifica l’utente e restituisce una risposta con un’asserzione, cioè una dichiarazione tecnica firmata che certifica l’avvenuta autenticazione. Le tracce, di conseguenza, sono distribuite. L’IdP conserva memoria di ogni autenticazione fatta, il SP conserva memoria dell’accesso e delle operazioni svolte nei propri sistemi. I due punti di osservazione non coincidono mai: l’uno vede la transazione, l’altro l’uso del servizio. Questa separazione è una garanzia per la privacy, perché impedisce che un solo soggetto abbia il quadro completo di tutto quello che una persona combina presso ogni amministrazione.
Il protocollo SAML 2.0 e cosa viaggia durante l’accesso
Le regole tecniche ruotano attorno al protocollo SAML 2.0, uno standard usato nei sistemi di Single Sign-On per scambiare informazioni di autenticazione. Nel flusso classico il SP crea una AuthnRequest che include l’identificativo del fornitore, il servizio richiesto, il livello di autenticazione e i parametri tecnici necessari. L’utente viene poi reindirizzato verso l’IdP, che dopo il riconoscimento produce una Response SAML. Se tutto fila liscio, dentro c’è un’Assertion firmata digitalmente con le informazioni per identificare la persona. Il Service Provider deve verificarla prima di accettarla, controllando firme, validità temporale, destinatario, emittente e coerenza col messaggio originale.
Dal lato dell’IdP vengono registrati tipicamente la data e l’ora della richiesta, l’identificativo del SP, il livello richiesto, l’esito, l’identificativo tecnico della transazione, il riferimento alla sessione, l’indirizzo IP di provenienza, informazioni su dispositivo o browser quando trattate dai sistemi di sicurezza, eventuali errori o tentativi falliti e l’uso di fattori aggiuntivi come gli OTP. Se qualcuno accede al sito dell’Agenzia delle Entrate, l’IdP sa che c’è stata un’autenticazione verso quel servizio, ma non vede quale dichiarazione è stata consultata né quale documento è stato scaricato.
Il SP, dal canto suo, racconta un’altra fetta della storia. Dopo aver verificato la risposta SAML, lega l’identità alla sessione e da lì gestisce gli eventi interni: pagine viste, pratiche aperte, istanze inviate, deleghe usate. Le regole impongono al SP di conservare per 24 mesi le informazioni che permettono di attribuire le operazioni alle singole identità digitali. Serve a poter dimostrare chi ha fatto cosa, magari quando un cittadino sostiene di non aver mai presentato una certa richiesta.
Sul fronte degli attributi SPID, non viene trasmesso tutto in automatico. Il SP richiede solo i dati necessari alla transazione: nome, cognome, codice fiscale, data e luogo di nascita, email o numero di telefono a seconda dei casi. Il codice fiscale è spesso quello decisivo nei servizi pubblici italiani. Quanto alla profilazione commerciale da parte degli IdP, semplicemente non è compatibile col sistema: i dati vanno usati per la sicurezza, la gestione dell’identità e gli obblighi normativi, non per costruire profili da vendere a terzi. Lo impongono sia le regole SPID sia il GDPR. AgID ha introdotto anche linee guida per integrare OpenID Connect, costruito su OAuth 2.0, dove cambiano formati e flussi ma resta l’esigenza di tracciare chi ha chiesto cosa e quando. In caso di contestazione o indagine, IdP, SP e provider di connettività possono fornire ciascuno la propria evidenza, e solo correlando più fonti si ricostruisce il quadro completo.