Chapter 2
Obiettivi Formativi:
- Comprendere i principi della SSI, i nuovi ruoli e il locus of control dell’utente
- Come funzionano i nuovi identificatori decentralizzati (p2p model) e come può utilizzarli un utente all’interno di un network.
- Identificare un utente tramite le credenziali verificabili, presentazioni verificabili e registri distribuiti (blockchain)
- Comprendere il ruolo dei wallet e Decentralized Key Management System.
- Come si relazione la Self-Sovereign Identity con i framework precedenti e la proposta Self-issued OpenID.
Chapter 2
Obiettivi Formativi:
- Comprendere i principi della SSI, i nuovi ruoli e il locus of control dell’utente
- Come funzionano i nuovi identificatori decentralizzati (p2p model) e come può utilizzarli un utente all’interno di un network.
- Identificare un utente tramite le credenziali verificabili, presentazioni verificabili e registri distribuiti (blockchain)
- Comprendere il ruolo dei wallet e Decentralized Key Management System.
- Come si relazione la Self-Sovereign Identity con i framework precedenti e la proposta Self-issued OpenID.
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.
- Existence — Gli utenti devono avere un’entità indipendente
- Control — Gli utenti devono controllare le loro identità
- Access — Gli utenti devono avere accesso ai loro dati personali
- Transparency — Gli algoritmi e i sistemi devono essere trasparenti
- Persistence — Le identità devono essere durature
- Portability — Le informazioni e i servizi riguardo alle identità devono essere “trasportabili”
- Interoperability — Le identità dovrebbero essere ampiamente utilizzabili
- Consent — Gli utenti devono consentire l’utilizzo delle loro identità
- Minimization — La divulgazione delle dichiarazioni degli utenti deve essere minimizzata
- Protection — Protezione dei diritti degli utenti
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.
- Existence — Gli utenti devono avere un’entità indipendente
- Control — Gli utenti devono controllare le loro identità
- Access — Gli utenti devono avere accesso ai loro dati personali
- Transparency — Gli algoritmi e i sistemi devono essere trasparenti
- Persistence — Le identità devono essere durature
- Portability — Le informazioni e i servizi riguardo alle identità devono essere “trasportabili”
- Interoperability — Le identità dovrebbero essere ampiamente utilizzabili
- Consent — Gli utenti devono consentire l’utilizzo delle loro identità
- Minimization — La divulgazione delle dichiarazioni degli utenti deve essere minimizzata
- 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 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.
- 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 identificatori decentralizzati (DID)
Nel mondo digitale e 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, infatti, forme di identificatori. Anche nel web, per esempio, le risorse e le pagine web anch’esse vengono associate ad identificatori chiamati URI (Uniform Resource Identifiers) e URL (Unique Resource Locator).
La maggior parte degli identificatori vengono associati alla propria identità da enti terzi come governi, associazioni, enti, aziende private, i quali possono gestirli e/o modificarli a posteriori e a loro di discrezione, assumendosi il rischio di gestione.
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.
I DID possono rappresentare ed essere associati anche a entità giuridiche e oggetti.
I nuovi identificatori decentralizzati (DID)
Nel mondo digitale e 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, infatti, forme di identificatori. Anche nel web, per esempio, le risorse e le pagine web anch’esse vengono associate ad identificatori chiamati URI (Uniform Resource Identifiers) e URL (Unique Resource Locator).
La maggior parte degli identificatori vengono associati alla propria identità da enti terzi come governi, associazioni, enti, aziende private, i quali possono gestirli e/o modificarli a posteriori e a loro di discrezione, assumendosi il rischio di gestione.
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.
I DID possono rappresentare ed essere associati anche a entità giuridiche e oggetti.
Come potete osservare in questo schema preso dal documento ufficiale del W3C, lo schema dell’identificatore standard è lo schema iniziale did, il did method (example), e il codice alfanumerico è il did method che unico e specifico della persona. Differente sarà network e distributed ledgers, differente sarà il did method. Tra i più famosi did:btcr (Bitcoin) e did:ethr (Ethereum), il numero dei did:method sta crescendo. L’effetto network potrebbe far tendere nel lungo periodo a pochi network principali.
- Secondo Capitolo (%) 14%
L’architettura dei decentralized identifiers (DID)
In questa sezione analizziamo i vari componenti nella architettura DID, ovvero il meccanismo attraverso cui i DID possono essere gestiti e comunicati e i vari elementi tecnici che funzionano tra di loro.
DID e DID URL
Un DID è una stringa alfanumerica 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 assoicato anche un DID URL. Il DID estende le sue proprietà tramite un URL.
Un DID URL estende infatti 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, viene utilizzato un software il quale prende l’URL del DID come input e produce una risorsa come output (questo processo è chiamato dereferencing).
Come potete osservare in questo schema preso dal documento ufficiale del W3C, lo schema dell’identificatore standard è lo schema iniziale did, il did method (example), e il codice alfanumerico è il did method che unico e specifico della persona. Differente sarà network e distributed ledgers, differente sarà il did method. Tra i più famosi did:btcr (Bitcoin) e did:ethr (Ethereum), il numero dei did:method sta crescendo. L’effetto network potrebbe far tendere nel lungo periodo a pochi network principali.
- Secondo Capitolo (%) 14%
L’architettura dei decentralized identifiers (DID)
In questa sezione analizziamo i vari componenti nella architettura DID, ovvero il meccanismo attraverso cui i DID possono essere gestiti e comunicati e i vari elementi tecnici che funzionano tra di loro.
DID e DID URL
Un DID è una stringa alfanumerica 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 assoicato anche un DID URL. Il DID estende le sue proprietà tramite un URL.
Un DID URL estende infatti 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, viene utilizzato un software il quale prende l’URL del DID come input e produce una risorsa come output (questo processo è chiamato dereferencing).
L’architettura dei decentralized identifiers (DID)
Documenti DID
I DID vengono accompagnati dei documenti DID ed, attraverso questi file, si possono utilizzare in un network e nella sfera pubblica. I documenti DID contengono altre informazioni utili per l’utilizzo e per la sicurezza dell’identificazione come:
- Il riferimento al DID specifico dell’utente x.
- Riconoscere 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 e 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).
L’architettura dei decentralized identifiers (DID)
Documenti DID
I DID vengono accompagnati dei documenti DID ed, attraverso questi file, si possono utilizzare in un network e nella sfera pubblica. I documenti DID contengono altre informazioni utili per l’utilizzo e per la sicurezza dell’identificazione come:
- Il riferimento al DID specifico dell’utente x.
- Riconoscere 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 e 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).
- Secondo Capitolo (%) 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’architettura 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.
- Secondo Capitolo (%) 30%
L’architettura 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.
DID Subject
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.
Quali sono i benefici dell’infrastruttura 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à. I DID sono:
- Inter-giurisdizionali – Gli identificatori inter-giurisdizionali non dipendono dalla giurisdizione del Paese in cui sono stati emessi.
- 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)
- Non generano un minimized rent – Questi identificatori non provocano spese agli issuer.
- Nessun monopolio – Gli identificatori non dipendono da alcun venditore.
- Self-issued, self-managed – Gli identificatori sono creati e gestiti dal soggetto o dall’identificatore.
- 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.
- No phone home – Quando gli identificatori vengono utilizzati, non vi è la necessità di contattare l’emittente dell’identificatore per verifica.
- No surveillance capitalism – Gli identificatori limitano l’efficacia del capitalismo di sorveglianza minimizzando la correlazione tra i servizi.
- Crittografia non subisce obsolescenza – Gli identificatori possono essere aggiornati qualora la tecnologia evolva.
- Sopravvivono alla scomparsa delle organizzazioni – Gli identificatori sopravvivono alla scomparsa delle organizzazioni che li hanno emessi.
- Survives deployment end-of-life – Questi identificatori sono utilizzabili anche dopo che i sistemi utilizzati dalle parti diventano obsoleti.
- Survives relationship with service provider – Gli identificatori sono indipendenti, permangono anche qualora il mandato del service provider venga meno.
- 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.
- Service discovery – Questi identificatori consentono alle parti di cercare servizi disponibili per comunicare con il soggetto cui l’identificatore si riferisce.
- Registry agnostic – Tali identificatori possono stare su qualsiasi registro che possieda un’interfaccia compatibile.
Quali sono i benefici dell’infrastruttura 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à. I DID sono:
- Inter-giurisdizionali – Gli identificatori inter-giurisdizionali non dipendono dalla giurisdizione del Paese in cui sono stati emessi.
- 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)
- Non generano un minimized rent – Questi identificatori non provocano spese agli issuer.
- Nessun monopolio – Gli identificatori non dipendono da alcun venditore.
- Self-issued, self-managed – Gli identificatori sono creati e gestiti dal soggetto o dall’identificatore.
- 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.
- No phone home – Quando gli identificatori vengono utilizzati, non vi è la necessità di contattare l’emittente dell’identificatore per verifica.
- No surveillance capitalism – Gli identificatori limitano l’efficacia del capitalismo di sorveglianza minimizzando la correlazione tra i servizi.
- Crittografia non subisce obsolescenza – Gli identificatori possono essere aggiornati qualora la tecnologia evolva.
- Sopravvivono alla scomparsa delle organizzazioni – Gli identificatori sopravvivono alla scomparsa delle organizzazioni che li hanno emessi.
- Survives deployment end-of-life – Questi identificatori sono utilizzabili anche dopo che i sistemi utilizzati dalle parti diventano obsoleti.
- Survives relationship with service provider – Gli identificatori sono indipendenti, permangono anche qualora il mandato del service provider venga meno.
- 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.
- Service discovery – Questi identificatori consentono alle parti di cercare servizi disponibili per comunicare con il soggetto cui l’identificatore si riferisce.
- Registry agnostic – Tali identificatori possono stare su qualsiasi registro che possieda un’interfaccia compatibile.
Le nuovi credenziali verificabili nello scenario di dematerializzazione
Abbiamo a che fare con il concetto di credenziali verificabile ogni giorno; 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.
Le nuovi credenziali verificabili nello scenario di dematerializzazione
Abbiamo a che fare con il concetto di credenziali verificabile ogni giorno; 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 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.
La figura in alto 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 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 verifcabile: i metadati della presentazione, le credenziale verificabili e le prove crittografiche.
Questa tecnologia crea sottoinsiemi di informazioni rilevanti riguardanti una persona. L’aggregazione di queste informazioni esprime un aspetto di una persona, un’organizzazione o entità richiesta per identificarsi o per accedere un servizio.
La figura a sinistra mostra la rappresentazione completa di presentazioni precedenti, dove utente dimostra di possedere una credenziale universitaria, senza mostrare il suo nome. Accedere alla biblioteca, senza lasciare i dati sensibili alla biblioteca
ll primo grafico esprime una 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 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 verifcabile: i metadati della presentazione, le credenziale verificabili e le prove crittografiche.
Questa tecnologia crea sottoinsiemi di informazioni rilevanti riguardanti una persona. L’aggregazione di queste informazioni esprime un aspetto di una persona, un’organizzazione o entità richiesta per identificarsi o per accedere un servizio.
La figura a sinistra mostra la rappresentazione completa di presentazioni precedenti, dove utente dimostra di possedere una credenziale universitaria, senza mostrare il suo nome. Accedere alla biblioteca, senza lasciare i dati sensibili alla biblioteca
ll primo grafico esprime una 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 nel network
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 deve includere una firma che provi che l’emittente desiderato ha generato la credenziale
- essere trasmessa in un modo chiaro e confermo allo standard, il quale standard 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à.
Il modello di fiducia per gli attori nel network
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 deve includere una firma che provi che l’emittente desiderato ha generato la credenziale
- essere trasmessa in un modo chiaro e confermo allo standard, il quale standard 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à.
- 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.
Gestione della root of trust e utilizzo dell’identità sovrana online
La fiducia verso il framework Self-Sovereign Identity (SSI) è dato dagli strumenti tecnologici che utilizza per garantire privacy, controllo e sicurezza di informazioni personali. Abbiamo visto nel capitolo che esistono molti did method sul mercato, offerti da aziende e ecosistemi che utilizzano la blockchain e il distributed ledger per business e cripto. In questa parte parleremo delle altre tecnologie definite tecnicamente come root of trust utilizzate per l’utilizzo, la interoperabilità e il custodia.
Gestione della root of trust e utilizzo dell’identità sovrana online
La fiducia verso il framework Self-Sovereign Identity (SSI) è dato dagli strumenti tecnologici che utilizza per garantire privacy, controllo e sicurezza di informazioni personali. Abbiamo visto nel capitolo che esistono molti did method sul mercato, offerti da aziende e ecosistemi che utilizzano la blockchain e il distributed ledger per business e cripto. In questa parte parleremo delle altre tecnologie definite tecnicamente come root of trust utilizzate per l’utilizzo, la interoperabilità e il custodia.
Blockchain, distributed ledger e network
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 sicurezza è data da pochi attaccati malevoli nel network per una buona sincronia di incentivi e l’asincronia degli utenti pseudo-anonimi. È definita come un registro digitale a forma di catena perché le cui voci sono raggruppate in “blocchi”, concatenati in ordine cronologico.
Utilizzando funzioni hash per correlare le informazioni e merkle tree per sommarizzare, ai dati viene garantita sicurezza, riservatezza ed immutabilità della transazione. Grazie a crittografia, distributed science e teoria dei giochi, una blockhain è un ottimo root of trust condiviso e pubblico.
- Secondo Capitolo (%) 57%
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 modello della Self-Sovreign Idenity SSI, il registro può essere utilizzata per i seguenti obiettivi:
- Verificare una credenziale
- Revocare una credenziale
- Creazione di un DID, in base al DID Method del protocollo
- Blacklisting di un DID segnalati
- Verifica del DID tramite DID Documents e verifica dei dati correlati al DID Controller e DID Subject
Blockchain, distributed ledger e network
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 sicurezza è data da pochi attaccati malevoli nel network per una buona sincronia di incentivi e l’asincronia degli utenti pseudo-anonimi. È definita come un registro digitale a forma di catena perché le cui voci sono raggruppate in “blocchi”, concatenati in ordine cronologico.
Utilizzando funzioni hash per correlare le informazioni e merkle tree per sommarizzare, ai dati viene garantita sicurezza, riservatezza ed immutabilità della transazione. Grazie a crittografia, distributed science e teoria dei giochi, una blockhain è un ottimo root of trust condiviso e pubblico.
- Secondo Capitolo (%) 57%
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 modello della Self-Sovreign Idenity SSI, il registro può essere utilizzata per i seguenti obiettivi:
- Verificare una credenziale
- Revocare una credenziale
- Creazione di un DID, in base al DID Method del protocollo
- Blacklisting di un DID segnalati
- Verifica del DID tramite DID Documents e verifica dei 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 multi-layer, 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.
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 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 multi-layer, 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.
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à completamente 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
- Secondo Capitolo (%) 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 decentralized (IPFS) o centralized 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.
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à completamente 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
- Secondo Capitolo (%) 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 decentralized (IPFS) o centralized 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, minizzando i dati mostrati per l’accesso ad un servizio online.
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 Self-Sovereign Identity (SSI) è di rendere scalabile e interoperabile l’identità digitale sovrana parlando con i framework esistenti. La OpenID Foundation insieme al DIF ha suggerito di integrare l’identità digitale sovrana con lo standard di autenticazione OpenID Connect.
Attualmente non è ancora stata implementata.
Analizziamo più nel dettaglio gli sviluppi fin’ora del interazione tramite OpedID Conncect, l’OpenID Provider e Self-Issued OpenID Provider.
Un OpenID Provider (OP) è un issuer che rilascia informazioni riguardo l’identità in forma di ID token. Inoltre esistono anche i token self-issued che invece sono token emesso da un Self-issued OpenID Provider. La relazione di trust in quest’ultimo caso è direttamente collegabile l’utilizzatore finale.
Un Self-issued OpenID Provider può presentare due tipologie di presentazioni verificabili, ovvero quelle sono contenti token self-issued oppure contenenti token emessi da esterno crittograficamente verificabili.
Come si relaziona la SSI con i protocolli d’identificazione in rete oggi
L’obiettivo della Self-Sovereign Identity (SSI) è di rendere scalabile e interoperabile l’identità digitale sovrana parlando con i framework esistenti. La OpenID Foundation insieme al DIF ha suggerito di integrare l’identità digitale sovrana con lo standard di autenticazione OpenID Connect.
Attualmente non è ancora stata implementata.
Analizziamo più nel dettaglio gli sviluppi fin’ora del interazione tramite OpedID Conncect, l’OpenID Provider e Self-Issued OpenID Provider.
Un OpenID Provider (OP) è un issuer che rilascia informazioni riguardo l’identità in forma di ID token. Inoltre esistono anche i token self-issued che invece sono token emesso da un Self-issued OpenID Provider. La relazione di trust in quest’ultimo caso è direttamente collegabile l’utilizzatore finale.
Un Self-issued OpenID Provider può presentare due tipologie di presentazioni verificabili, ovvero quelle sono contenti token self-issued oppure contenenti token emessi da esterno crittograficamente verificabili.
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, minizzando i dati mostrati per l’accesso ad un servizio online
Ciò permette agli utilizzatori di interagire con terzi senza contare su un provider esterno..
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: Self-issued OP risolve il problema
2.2. Autenticazione – Self-Issued OP fornisce un’autenticazione diretta, senza dover utilizzare OP remoti, velocizzando il processo.
2.3. Condivisione di credenziali in un’unica transazione – 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ù servizi sotto un unico self-issued OP – Gli utilizzatori finali solitamente utilizzano diversi Hosted Open 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.
Il modello Self-issued OP singolo permette invece di andare incontro a un’esigenza di privacy e facilità di utilizzo, utilizzando il trust reputazionale dell’emittente della credenziale.
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: Self-issued OP risolve il problema
2.2. Autenticazione – Self-Issued OP fornisce un’autenticazione diretta, senza dover utilizzare OP remoti, velocizzando il processo.
2.3. Condivisione di credenziali in un’unica transazione – 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ù servizi sotto un unico self-issued OP – Gli utilizzatori finali solitamente utilizzano diversi Hosted Open 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.
Il modello Self-issued OP singolo permette invece di andare incontro a un’esigenza di privacy e facilità di utilizzo, utilizzando il trust reputazionale dell’emittente della credenziale.