L'identità digitale ti fa accedere a servizi online attraverso un sistema di riconoscimento condiviso. Parto dall'esperienza di accesso con SPID per spiegare chi sono gli attori coinvolti e che cos'è l'autenticazione federata — tenendo separati tre concetti che si confondono sempre: identità, autenticazione e autorizzazione.

Utente, gestore dell'identità e servizio

Tu vuoi usare un servizio, per esempio un portale della pubblica amministrazione. Il fornitore del servizio deve riconoscerti; il gestore dell'identità esegue l'autenticazione e comunica l'esito secondo le regole previste.

Il vantaggio è non dover costruire un meccanismo di riconoscimento nuovo per ogni portale. Attenzione però: non significa che i soggetti non si scambino informazioni. Quello scambio è esattamente ciò che rende possibile il processo, e per questo va regolato e protetto.

Il percorso di accesso

Nel flusso SPID basato su SAML scegli il gestore dell'identità dal sito del servizio, vieni indirizzato verso l'autenticazione e torni con una risposta che contiene un'asserzione firmata. Il servizio verifica quello che ha ricevuto e applica le proprie regole di accesso. La sequenza è descritta nelle regole tecniche SPID.

Riconoscere chi accede e decidere che cosa può fare sono due passaggi collegati e distinti. Confonderli è l'errore che rende incomprensibile tutto il resto.

OAuth e OpenID Connect: una distinzione necessaria

Qui ho sovrapposto dei concetti e li separo. OAuth 2.0 riguarda la delega dell'autorizzazione; OpenID Connect aggiunge un livello per l'autenticazione e le informazioni sull'identità. L'ID token appartiene al secondo, e non è il nome generico di ogni messaggio SPID.

Le specifiche SPID/CIE OpenID Connect documentano questa famiglia di integrazioni. Ma non tutti gli accessi SPID passano dallo stesso flusso OIDC, e descriverli così sarebbe impreciso.

Sicurezza e standard aperti

Cifratura, firme, verifiche e regole di fiducia proteggono il processo. Non lo rendono infallibile: implementazione, gestione delle credenziali e comportamento di chi accede contano quanto il protocollo.

Un'altra distinzione: standard aperto e software open source non sono sinonimi. Il primo riguarda specifiche e interoperabilità, il secondo il codice e la sua licenza. E poter esaminare un'implementazione non garantisce che gli errori vengano corretti in fretta.

Le possibilità future restano ipotesi

Immagino altre integrazioni fra documenti e identità digitale. Sono ipotesi, non funzioni disponibili — e nemmeno la dimostrazione che concentrare tutto in un solo gestore sia preferibile.

La domanda da tenere aperta è come rendere i servizi accessibili, verificabili e rispettosi dei dati delle persone. Le tre cose insieme, non a turno.