Che ruolo hanno i Did Auth e i Decentralized Key Management System?

• Che cos’è un DID Auth?
• Che cos’è un DKMS?
• Il workflow per la verifica dell’identità su SSI
• Perché sono fondamentali per la SSI?

Siamo tornati con la quinta guida su Self Sovereign Identity dove spiegheremo il funzionamento dei DID Auth e dei Decentralized Key Management System (DKMS), i due altri pilastri tecnologici che, insieme ai Decentralized Identifiers e Verifiable Credentials,  risultano fondamentali per la realizzazione di questo nuovo standard relativo all’identità digitale.

Che cos’è un DID Auth?

Nel mondo della Self Sovereign Identity, una delle prime domande che gli utenti si devono chiedere è: ma se non vi è nessuno che mi fornisce l’identità, come faccio a dimostrare a terzi che io esisto? 

Abbiamo spiegato nella scorse guide che la mia identità digitale è data da ciò che che altri utenti dicono di me all’interno di un mondo virtuale, dove l’identità personale è caratterizzata da identificatori decentralizzati (DID). Un mondo di DID che si connettono l’uno con l’altro. Più tecnicamente, possiamo immaginare la nostra identità come una identità funzionale che è determinata dalle credenziali verificabili che soggetti terzi ci forniscono e dalle connessioni che il nostro DID ha creato con altri peers. Tuttavia, il problema si sposta. Se io stesso controllo e genero il mio DID, come faccio a comprovare che tale DID è controllato da me medesimo e mi rappresenta? 

Entra qui in gioco il ruolo dei DID Auth. 

Il termine DID Auth è stato usato in diversi modi e attualmente non ha ancora una definizione ben specifica. Tuttavia, possiamo definire DID Auth come una cerimonia virtuale in cui un proprietario di una identità digitale, con l’aiuto di vari componenti come browser web e dispositivi mobili dimostra a una controparte che ha il pieno controllo di uno specifico DID in quel preciso momento. Chiaramente, quando si parla di DID Auth si include la capacità di stabilire canali di comunicazione reciprocamente autenticati e/o la capacità di autenticarsi tramite il proprio DID tramite siti Web e/o applicazioni digitali. 

Più tecnicamente, per dimostrare il controllo di un DID verso una controparte si utilizza un meccanismo che viene descritto e specificato all’interno di quelli che abbiamo definito nella scorsa guida DID document o documento DID. 

I DID Document possiamo immaginarli come dei libretti di istruzioni che accompagnano i DID, all’interno dei quali vi sono diversi metadati che aiutano le controparti ad identificare la controparte durante una connessione. Tuttavia, alcune informazioni relative alle modalità di identificazione coinvolgono i Decentralized Key Management System (DKMS), quindi andiamo per ordine. 

Che cos’è un DKMS?

Nel mondo offline, gestiamo le nostre credenziali all’interno in un portafoglio fisico: questo perché ci aiuta a non perderle, a proteggerle tenendole vicine al nostro corpo e le rende facili da trasportare ed accessibili quando ne abbiamo bisogno. Il lavoro di un portafoglio digitale non dovrebbe essere diverso: dovrebbe memorizzare le tue credenziali, tenerle al sicuro da potenziali hacker o attacchi informatici ed infine dovrebbero essere comode da mostrare attraverso tutti i propri dispositivi, ma al contempo, facili da nascondere ad occhi indiscreti.

Sfortunatamente, nel corso degli anni 90 e 00 ci sono stati così tanti tentativi sbagliati di portafogli digitali che molti sviluppatori hanno smesso di usare il termine. Tuttavia, con la nascita delle criptovalute, la ricerca e lo sviluppo dei famosi crypto wallet ha ridato finalmente la luce a queste applicazioni digitali. 

Queste tipologie di wallet si basano su una branca della matematica, più precisamente della crittografia, definita come crittografia a chiave pubblica o crittografia asimmetrica. L’idea è la seguente: un utente possiede una chiave privata, che deve essere tenuta al sicuro e non deve essere mostrata a nessuno, e possiede una chiave pubblica che invece può mostrare e che abilità all’utente di identificarsi verso le controparti. Dalla chiave pubblica non si ottiene nessuna informazione rispetto alla chiave privata, tuttavia quest’ultima è generata univocamente dalla chiave privata. 

Tramite l’utilizzo della chiave privata, l’utente può operare e “sbloccare” operazioni e la chiave pubblica servirà per dimostrare a terzi che tali operazioni sono state eseguite da lui stesso. Per esempio, nel caso di Bitcoin, la chiave privata abilita l’utente a spendere i bitcoin mentre la chiave pubblica (più precisamente una sua rappresentazione ridotto, definita come indirizzo pubblico) viene mostrata per ricevere da terzi altri bitcoins.

Ma che relazioni ci sono tra queste chiave e gli elementi della Self Sovereign Identity? Semplice, ogni DID è immaginabile come indirizzo pubblico generato da una chiave pubblica che a sua volta è stata generata da una chiave privata. Ti ricordo, inoltre, che la direzione delle generazioni è unidirezionale, ovvero che dal DID non potrò mai risalire alla chiave privata, ma contrariamente dalla chiave privata potrà risalire al mio DID. Quindi, un wallet per la SSI dovrà essere un contenitore per questi 3 elementi fondamentali ed è lo strumento proprietario che abilita l’utente ad effettuare operazioni e connessioni con altri utenti. 

Inoltre, differentemente da un tradizionale wallet crypto (per chi di voi ha già qualche esperienza in materia Bitcoin etc) un DKMS dovrà avere anche queste funzioni:

• Dovrà rispettare standard aperti della Self Sovereign Identity;
• Dovrà permettere connessioni per eseguire lo scambio di credenziali verificabili (VCs) tra agenti durante le identificazioni;
• Dovrà facilmente essere connesso ad altri sistemi tramite API o altri protocolli di comunicazioni informatici;
• Dovrà accettare e risolvere qualsiasi tipologia di credenziale verificabile (VC) in base alla sua estensione;
• Dovrà essere installabile su qualsiasi dispositivo;
• Dovrà essere possibile facilmente  effettuare i backup e spostare chiavi e credenziali da un portafoglio all’altro;

Tra l’altro, se ci pensate bene, tutte queste caratteristiche sono state pensate per creare una copia digitale, o come spesso si utilizza un “digital twin” del nostro vecchio portafoglio in pelle che utilizziamo quotidianamente: facile da utilizzare, da portare in giro, da riempire e da svuotare. 

Il workflow per la verifica dell’identità su SSI

Cerchiamo adesso di capire come funziona la relazione tra DID Auth e i DKMS per quanto concerne la verifica di una identità su SSI.

Abbiamo detto che i DID Auth è un meccanismo che permette ad un utente di dimostrare a terzi di possedere un identificatore decentralizzato (DID). Mentre, i DKMS sono dei contenitori all’interno dei quali vi sono i DID e le chiavi crittografiche. Inoltre, abbiamo citato prima come vengano utilizzati i DID Document per aiutare l’utente a dimostrare di possedere un determinato DID. Ma effettivamente cosa vuol dire?

All’interno di DID Document generico è possibile trovare diversi campi, tra questi a noi interessa quello definito “autenticazione”. L’autenticazione concerne l’utilizzo delle proprie chiavi crittografiche, quindi chiave pubblica e chiave privata, associate al DID.

Grazie alla chiave privata, l’utente potrà risolvere una challenge creata dal DID Auth e grazie alla sua chiave pubblica potrà mostrare di aver risolto questa challenge. Questa risoluzione è definita una prova crittografica.

La prova crittografica è un valore alfanumerico che è segnalato all’interno del documento DID, così da essere pubblico per tutte le parti coinvolte nel procedimento di verifica.

Questo meccanismo di prova verrà effettuato dall’utente tramite il suo DKMS, il quale comunicherà con il DID Auth della controparte, immaginabile come un bottone “Sign in with DID Auth” all’interno di un sito web o di una applicazione. Attraverso questa modalità, l’utente potrà identificarsi verso terzi e dimostrare di possedere quel DID. 

Perché sono fondamentali per la SSI?

I motivi sono diversi: il primo tuttavia, è uno dei più importanti. 

Uno dei grandi benefici della Self Sovereign Identity è la possibilità di poter creare centinaia e centinaia di proprie identità in base alle relazioni e alle connessioni che un utente vuole creare. Più tecnicamente vuol dire che un utente potrebbe creare un nuovo DID per ogni nuova relazione che sta creando. Questo, tuttavia, vorrebbe dire memorizzare centinaia e centinaia di codici alfanumerici, cosa che sfido chiunque a riuscire a farlo, senza impazzire. I DKMS servono proprio ad avere dei contenitori facili da utilizzare, all’interno dei quali un utente generico può facilmente ritrovare e maneggiare tutte le sue identità.

Secondo, grazie al DID Auth, la Self Sovereign Identity potrà competere con le altre modalità di riconoscimento digitale in maniera simile ai “Login With Facebook” etc. Ricordiamo sempre che la user experience e la faciltà di utilizzo sono i principi scogli quando si parla di adozione.

Terzo, la challenge del DID Auth possiamo considerarla come un “speciale“ verifiable credentials. Speciale perché solo dopo la risoluzione della challenge del DID Auth, le altre verifiable credentials possono essere scambiate (durante eventuali altre verifiche), e quindi la prova del DID Auth risulta parte integrante del controllo dell’identità.

Con questa guida abbiamo capito meglio quali sono tutti gli elementi fondamentali per la realizzazione della Self Sovereign Identity. Inoltre, nella prossima guida vedremo finalmente il reale utilizzo della blockchain all’interno di questo nuovo meccanismo di identity management.