Chapter 2

Obiettivi Formativi:

  • I principi della SSI e i nuovi ruoli
  • Nuovi identificatori decentralizzati (p2p model)
  • Credenziali digitali e registri distribuiti (blockchain)
  • Decentralized Key Management System, 
  • Self-issued OpenID e relazione con i framework precedenti

I principi della Self-Sovereign Identity (SSI)

Immagina di trasferirti in un nuovo Paese e di doverti registrare per fruire di qualsiasi tipo di servizio: votare, prendere la patente, servizio elettrico, nuove coordinate bancarie. Al momento, per aprire un nuovo account è necessario registrarsi con ogni nuovo service provider e dimostrare la propria identità ed ogni volta, per accedere, è necessario dimostrare la propria identità, inserendo password e credenziali. Un’identità decentralizzata semplificherebbe radicalmente tale processo. Essa dovrebbe soddisfare alcuni principi per far sì che non abbia gli stessi problemi e le stesse limitazioni dei precedenti modelli.

  1. Existence — Gli utenti devono avere un’entità indipendente
  2. ControlGli utenti devono controllare le loro identità
  3. AccessGli utenti devono avere accesso ai loro dati personali
  4. Transparency — Gli algoritmi e i sistemi devono essere trasparenti
  5. Persistence — Le identità devono essere durature
  6. Portability — Le informazioni e i servizi riguardo alle identità devono essere “trasportabili”
  7. Interoperability — Le identità dovrebbero essere ampiamente utilizzabili
  8. Consent — Users devono consentire l’utilizzo delle loro identità
  9. Minimization — La divulgazione delle dichiarazioni degli utenti deve essere minimizzata
  10. Protection — Protezione dei diritti degli utenti
  • verifiable data registry: il sistema che media la creazione e la verificazione degli identificatori e altri dati rilevanti, come i diagrammi delle credenziali verificabili, i registri di revoca e le chiavi pubbliche dell’issuer.

I nuovi ruoli nel modello SSI

Una gestione autonoma e decentralizzata della propria identità digitale, corrisponde ad un necessario adattamento dei ruoli all’interno dell’identity management system:

  • holder: chi possiede una o più credenziali verificabili e genera presentazioni da esse
  • issuer: il ruolo di chi afferma le dichiarazioni di uno o più soggetti, creando credenziali verificabili e trasmettendole all’holder
  • subject: l’entità alla quale si riferiscono le dichiarazioni. Nella maggior parte dei casi coincide con l’holder, ma non sempre. (Es.: il genitore possiede le credenziali del figlio)
  • vérifier: il ruolo di chi riceve una o più credenziali, eventualmente all’interno di una presentazione, per processare e verificarle.

I nuovi identificatori decentralizzati (DID)

Sia nel mondo digitale, sia nel mondo fisico, la nostra identità è riconosciuta ed associata ad identificatori: Indirizzi di comunicazione (numeri telefonici, indirizzi e-mail), numeri ID (per passaporti, patenti di guida, assicurazione sanitaria) e identificatori di prodotto (numeri seriali, codici  barre) sono forme di identificatori. Anche nel web, le risorse e le pagine web precise sono associate agli identificatori chiamati URI (Uniform Resource Identifiers) e URL (Unique Resource Locator).

La maggior parte degli identificatori vengono associati alla propria identità da enti terzi, i quali possono gestirli e/o modificarli a posteriori.

 

 

I Decentralized Identifiers (DID) costituiscono una nuova tipologia di identificatori univoci, simili agli URI con firme e crittografia, creati per permettere ad individui ed organizzazioni di generare e possedere i loro identificator, senza la necessità di una controparte fiduciaria.Ogni entità può avere più DID, necessari per mantenere separate varie identità ed interazioni.

Come potete osservare in questo schema preso dal documento ufficiale del W3C, lo schema è did, il did method è example, mentre il codice alfanumerico è il did method specifico della persona. Differente sarà network e distributed ledgers, differente sarà anche il did method.

L’archittetura dei decentralized identifiers (DID)

In questa sezione analizziamo i vari componenti nella architettura DID e come funzionano tra di loro.

DID e DID URL

Un DID è una stringa che rappresenta la nostra identità. Tecnicamente, un DID è URI ad hoc composto da tre parti: lo schema did:, un identificatore di metodo ed un unico identificatore specificato dal metodo DID. Un DID può avere anche un DID URL.

Un DID URL estende la sintassi del DID base al fine di incorporare altre componenti standard URI per collocare altre risorse specifiche correlate al soggetto in possesso del DID. Per produrre una risorsa dal DID URL, si ha bisogno del dereferenziatore DID URL, il quale prende l’URL del DID come input e produce una risorsa come output (questo processo è chiamato dereferencing).

L’archittetura dei decentralized identifiers (DID)

Documenti DID 

I DID vengono accompagnati dei documenti DID ed attraverso questi file riescono ad essere utilizzati in diverse circostanze nella sfera pubblica. I documenti DID contengono informazioni associate al DID, come:

  • Il riferimento al DID specifico
  • I metodi di verifica tramite chiavi crittografiche
  • I metodi di autenticazione
  • I service endpoints esterni per le interazioni a posteriori
  • La data di creazione del DID (timestamp)
  • La firma del creatore del DID per l’integrità dello stesso 

In base al DID method, cambia il meccanismo con cui un particolare tipo di DID e il suo documento corrispondente sono creati, risolti, aggiornati e disattivati.

    DID resolvers and DID resolution

    Il risolutore DID è una componente di sistema che prende come input il DID e produce come output un documento DID conforme. Questo processo è chiamato risoluzione DID. Gli step per risolvere uno specifico tipo di DID sono definiti dal metodo DID pertinente.

    Per essere risolvibili in documenti DID, i DID sono registrati su un sistema sottostante o un network. A prescindere dalla tecnologia usata, qualsiasi sistema supporti la registrazione dei DID e la restituzione dei dati per la creazione di un documento DID è chiamato registro di dati verificabili (verifiable data registry). 

    • Primo Capitolo (%) 30% 30%

    DID subjects

    Il soggetto di un DID è, per definizione, l’entità identificata dal DID. Il soggetto del DID non dev’essere per forza una persona, può essere identificato anche con un’organizzazione, un gruppo, un oggetto o un concetto.

    Per approfondire l’argomento, qui il link del documento del W3C, dove pone gli standard da seguire ai vari protocolli e network.

    L’archittetura dei decentralized identifiers (DID)

    C’è da fare una netta distinzione tra chi controlla il DID e a chi è associato al DID, sopratutto in situazioni parentali e/o con limitazioni nella sfera pubblica.

    DID controllers

    Il controllore di un DID è un’entità (persona, organizzazione o un server autonomo) che ha la capacità di apportare modifiche ad un documento DID. Tale capacità è tipicamente affermata dal controllo di una serie di chiavi crittografiche usate dal software che agisce per conto del controllore. Un DID può avere anche più di un controllore ed il soggetto DID può essere il controllore stesso. 

      Le features dei DID

      In questa tabella ripresa dal documento del w3c, analizziamo vari aspetti che rendono i DID migliori degli identificatori del passato per la gestione dell’identità.

      1. Inter-giurisdizionali – Gli identificatori inter-giurisdizionali non dipendono dalla giurisdizione del Paese in cui sono stati emessi.
      1. Non possono essere cancellati amministrativamente – Questi identificatori non possono essere cancellati o sottratti da funzioni amministrative. Questo previene le interferenze da instabilità politica. (anti-censura)
      1. Minimized rents – Questi identificatori non provocano spese se inutilizzati
      1. Nessun monopolio – Gli identificatori non dipendono da alcun venditore
      1. Self-issued, self-managed – Gli identificatori sono creati e gestiti dal soggetto o dall’identificatore
      1. Rotazione semplificata – Quando il materiale necessita di essere aggiornato, gli identificatori possono essere aggiornati senza il diretto intervento delle parti e con minimo intervento dell’individuo.
      1. No phone home – Quando gli identificatori vengono utilizzati, non vi è la necessità di contattare l’emittente dell’identificatore per verifica.
      1. No surveillance capitalism – Gli identificatori limitano l’efficacia del capitalismo di sorveglianza minimizzando la correlazione tra i servizi.

       

         

        1. Crittografia non subisce obsolescenza – Gli identificatori possono essere aggiornati qualora la tecnologia evolva.
        1. Sopravvivono alla scomparsa delle organizzazioni – Gli identificatori sopravvivono alla scomparsa delle organizzazioni che li hanno emessi.
        1. Survives deployment end-of-life – Questi identificatori sono utilizzabili anche dopo che i sistemi utilizzati dalle parti diventano obsoleti. 
        1. Survives relationship with service provider – Gli identificatori sono indipendenti, permangono anche qualora il mandato del service provider venga meno.
        1. Cryptographic authentication and communication – Gli identificatori permettono l’autenticazione degli individui tramite tecniche crittografiche, e consentono inoltre comunicazioni sicure con il soggetto a cui l’identificatore si riferisce, utilizzando chiavi pubbliche-private.
        1. Service discovery – Questi identificatori consentono alle parti di cercare servizi disponibili per comunicare con il soggetto cui l’identificatore si riferisce.
        1. Registry agnostic – Tali identificatori possono stare su qualsiasi registro che possieda un’interfaccia compatibile.

        Le nuovi credenziali verificabili nello scenario di dematerializzazione

        Le credenziali sono parte del nostro quotidiano; le patenti, i diplomi di laurea e i passaporti sono delle credenziali che attestano alcuni dei nostri attributi. Si rende quindi necessario un meccanismo che permetta di esprimere queste credenziali sul Web in maniera tale da rispettare la privacy degli individui e che sia crittograficamente sicuro.

        Nel mondo fisico, una credenziale può consistere in:

        • un’informazione connessa al riconoscimento del soggetto della credenziale (una foto, il nome, un numero identificativo)
        • un’informazione connessa all’autorità emittente (un municipio, un’agenzia nazionale)
        • un’informazione connessa alla tipologia di credenziale (un passaporto olandese, una patente americana, una carta di assicurazione sanitaria)
        • un’informazione connessa a specifici attributi o proprietà affermati dall’autorità emittente riguardo il soggetto (nazionalità, data di nascita, tipologia di veicolo che può guidare)

        Con lo standard W3C, una credenziale verificabile è in grado di rappresentare tutte le informazioni possiede una credenziale fisica. I possessori di una credenziale verificabile possono generare presentazioni verificabili e mostrarle con i verificatori, rimanendo in possesso di esse.

        La figura a destra mostra il ruolo dei tre elementi che compongono il data model di una credenziale verificabile, nello scenario di verifica di possesso di una credenziale accademica. La prova sarà la validità della firma digitale della università di rimerimento. 

        L’attributo dell’utente è essere uno studente,  la firma tramite chiave pubblica di una università attesta l’attributo, il metadati sono le altre tue informazioni in quella precisa credenziale.

        Tuttavia, come andremo a vedere, grazie alle presentazioni verificabili è possibile mostrare un dato, garantendone la validità senza altri dati correlati.

           

          Il data model di una credeziale verificabile (VC)

          Una credenziale verificabile è un insieme di affermazioni e dati, non violabili, che comprovano crittograficamente chi li ha emessi. La credenziale può essere firmata dell’emittente. 

          La figura a sinistra mostra le componenti base di una credenziale: i metadati standard, gli attributi e una prova crittografica di sicurezza.

          Il data model della Presentazione Verificabile

          Uno tra i più interessanti principi da seguire c’è il concetto di minimizzare il dato, ovvero mostrare solo i dati necessari. Per garantire la minimizzazione del dato, l’utente dalle sue credenziale può combinare una presentazione con le informazioni richieste. La figura a sinistra mostra le componenti di una presentazione: i metadati della presentazione, le credenziale verificabili e le prove crittografiche.

          Questa tecnologia crea sottoinsiemi di informazioni riguardanti una persona viene definito presentazione verificabile.L’aggregazione di queste informazioni esprime un aspetto di una persona, un’organizzazione o entità.

          La figura a sinistra mostra invece la rappresentazione completa di una presentazione, che è normalmente composta da almeno quattro informazioni grafiche. Il primo grafico esprime la presentazione verificabile, che contiene i rispettivi metadata. La presentazione si riferisce a una o più credenziali, contenute nel secondo grafico. Il terzo grafico corrisponde alla firma digitale riferita alla credenziale, mentre il quarto contiene la firma provante la presentazione verificabile.

             

              • Il possessore e il verificatore contano che l’emittente emetta vere credenziali riguardo al soggetto, e che le revochi qualora risultino inappropriate.
              • Il possessore conta che le credenziali vengano archiviate in modo sicuro, che non vengano rilasciate a terzi, e che non vengano manomesse o perse.

              Questo modello si differenzia dagli altri in quanto l’emittente non necessita di conoscere il verificatore.

            Il modello di fiducia per gli attori

            Il modello di fiducia tra gli attori che utilizzano le credenziali verificabili prevede che:

            • Il verificatore conta che l’emittente emetta la credenziale che ha ricevuto. Per stabilire questo trust, la credenziale dovrebbe:
              • includere una firma che provi che l’emittente ha generato la credenziale

            oppure

            • essere trasmessa in un modo chiaro, il quale stabilisce che l’emittente ha generato la credenziale verificabile e che la credenziale non è stata manomessa.
            • Tutte le entità contano che il registro dati sia anti-manomissione e che sia una corretta annotazione di dati controllati dalle entità.

            Gestione della root of trust e utilizzo dell’identità sovrana online

            La fiducia verso il framework SSI è dato dagli strumenti tecnologici che utilizza per garantire privacy, controllo e sicurezza di informazioni personali. Abbiamo visto nel sottocapitolo # che esistono molti did method sul mercato, offerto su aziende e ecosistemi che utilizzano la blockchain e il distributed ledger per business e cripto. In questa parte parleremo delle altre tecnologie utilizzate per l’utilizzo, la interoperabilità e il custodia.

              Blockchain, distributed ledger e network

              Nel framework SSI, la blockchain è un registro utilizzato come root-of-trust pubblico, condiviso e democratico, dove nessuno può fare enforcing su di esso. Cerchiamo di capire meglio perché.

              La blockchain (letteralmente “catena di blocchi”) è una struttura dati condivisa. La sua immutabilità è data da pochi attaccati malevoli nel network per una buona sincronia di incentivi.È definita come un registro digitale le cui voci sono raggruppate in “blocchi”, concatenati in ordine cronologico. Utilizzano funzioni hash per correlare le informiazioni e merkle tree per sommarizzare i dati e per garantire immutabilità della transazione.

              Grazie a crittografia, distributed science e teoria dei giochi, una blockhain è un ottimo root of trust condiviso e pubblico.

               

              • Primo Capitolo (%) 91% 91%

              Tali tecnologie sono incluse nella più ampia famiglia dei Distributed Ledger, ossia sistemi che si basano su un registro distribuito, che può essere letto e modificato da più nodi di una rete.

              All’interno del business model della SSI, la blockchain può essere utilizzata per i seguenti obiettivi:

              • Verifica di una credenziale
              • Revoca di una credenziale
              • Creazione di un DID, in base al DID Method del protocollo
              • Blacklisting di un DID
              • Verifica dei DID Document e dati correlati al DID controller e DID Subject

              Il lavoro del Resolver è quello di scoprire e recuperare queste informazioni aggiuntive. Queste informazioni contengono elementi come servizi per comunicare con le entità, e le chiavi crittografiche ad essi associate.

              Questo permette la costruzione di formati di dati e protocolli sul layer dell’identificatore, a prescindere dalla blockchain utilizzata per registrare l’identificatore. Internamente, l’Universal Resolver raggiunge questo obiettivo attraverso la sua architettura formata da un driver per ogni tipo di identificatore supportato.

              Universal Resolver e interoperabilità

              Per migliorare i risolutori dei DID document e garantire maggiore interoperabilità è stata pensata la tecnologia dell’Universal Resolver. Questo risulta importante, perché gli identificatori sono la base per i sistemi di comunicazione ed identificazione; senza gli identificatori, non possiamo avere relazioni, transazioni,condivisione di dati tra entità. 

              L’Universal Resolver ci permette di costruire architetture e protocolli sugli identificatori self-sovereign. Non vi è più la necessità di un’autorità centrale che emetta, mantenga o revochi gli identificatori.

              Una blockchain basata sui DID che supporta l’Universal Resolver deve definire e implementare un driver DID che colleghi il Resolver al metodo DID utilizzato per leggere i documenti DID.

              Il portafoglio digitale (crypto wallet o dkms)

              Un wallet digitale, nel contesto della self-sovereign identity, è un’applicazione e database criptato che archivia credenziali, chiavi e altri “segreti” necessari per un’identità self-sovereign. Le credenziali sono emesse, trasferite e verificate attraverso l’utilizzo di wallet digitali.


              Tecnicamente questi wallet vengono definiti come DKMS (Decentralized Key Management System) derivante dal nuovo approccio di Key Management utilizzato con la blockchain e distributed ledger technologies (DLTs) nel quale non esistono più autorità centrali. Con DKMS, l’iniziale “rapporto di fiducia” tra tutti i partecipanti consiste in ogni distributed ledger che supporta una nuova forma di registro d’identità chiamato DID.

               

              L’architettura DKMS apporta i seguenti benefici:

              • Nessun single point of failure
              • Interoperabilità
              • Infrastruttura forte e flessibile
              • Recupero delle chiavi
              • Primo Capitolo (%) 91% 91%

              L’architettura DKMS si basa su tre livelli: 

              Il livello DID è quello fondamentale, composto da DID registrati e risolti tramite distributed ledgers.

              Il livello cloud è composto da wallet ed agents che permettono la comunicazione e la mediazione tra il livello DID ed il livello edge. Questo layer permette la comunicazione peer-to-peer per gli scambi e la verificazione dei DID, chiavi pubbliche e credenziali verificabili.

              L’edge layer è composto da dispositivi mobili, agents, wallet utilizzati direttamente dai possessori dell’identità per generare e immagazzinare chiavi private ed eseguire operazioni di gestione.

                OpenID Connect definisce un meccanismo tramite cui un End User può utilizzare a proprio vantaggio un OpenID Provider per rilasciare informazioni riguardo l’identità a una terza parte. Questa specificazione definisce il concetto di Self Issued OpenID Provider, ovvero un provider sotto il controllo dell’utilizzatore finale. Quest’ultimo può così autenticarsi in autonomia e presentare affermazioni a parti terze. Ciò permette agli utilizzatori di interagire con terzi senza contare su un provider esterno. 

                 

                Come si relaziona la SSI con i protocolli d’identificazione in rete oggi

                L’obiettivo della SSI è di rendere scalabile e interoperabile l’identità digitale sovrana parlando con i framework esistenti. La OpenID Foundation insieme al SIF ha suggerito di integrare l’identità digitale sovrana con lo standard di autenticazione OpenID Connect. 

                Analizziamo più nel dettaglio.

                Un OpenID Provider (OP) rilascia informazioni riguardo l’identità in forma di ID token. Un token Self-issued è invece un token emesso da un Self-issued OpenID Provider. La relazione di trust in quest’ultimo caso è direttamente con l’utilizzatore finale.

                Un Self-issued OpenID Provider può presentare due tipologie di credenziali verificabili, ovvero self-issued oppure emesse da un emittente esterno e rimangono comunque crittograficamente verificabili.

                I vantaggi del sistema SSI tramite Self-Issued OP

                I vantaggi del Self-Issued Op possono essere:

                2.1. Resilienza contro inoperabilità dell’OP – L’infrastruttura di un OpenID Provide può risultare non disponibile o distrutta a causa di eventi naturali. Un OP Self-issued risolve il problema

                2.2. AutenticazioneUn Self-Issued OP fornisce un’autenticazione diretta, senza dover utilizzare OP remoti. Ciò permette un’elevata efficienza in fase di autenticazione soprattutto in ambienti dove la connettività è ridotta.

                2.3. Condivisione di credenziali in un’unica transazioneUn Self-issued OP rappresenta direttamente l’user, può quindi avere a disposizione un enorme set di informazioni che un OP tradizionale non ha.

                2.4. Aggregazione di più individui sotto un unico self-issued OPGli utilizzatori finali solitamente utilizzano diversi Hosted Oen ID Provider per diverse parti terze. Tale utilizzo può creare delle frizioni qualora l’user ritorni in un secondo momento e non ricordi l’OP utilizzato in precedenza.

                Un self-issued OP singolo permette invece di andare incontro a un’esigenza di privacy e facilità di utilizzo. La capacità di presentare le credenziali permette a terze parti di accettare i token self-issued quando ancora gli attributi sono in fase di valutazione, utilizzando il trust reputazionale dell’emittente della credenziale.