Il problema di oggi con l’identità che ci rapprensenta in internet ( identità digitale ) si può riassumere con una frase “ TRUST a livello mondiale “.
Quando navighiamo in internet ci sono alcune considerazioni da fare sempre:
– Ci fidiamo della persona con la quale stiamo parlando ?
– E’ veramente una persona ?
– Quello che sta dicendo è vero ?
Come non riportare la vignetta del 1993 : “ On the internet nobody knows you’re a dog “
Per non parlare poi del dark o deep web che però nasce appositamente per creare anonimato e quindi va considerato in altro modo.
Questo perché ormai ci siamo accorti tutti che esiste un mondo parallelo nel quale viviamo molte ore del nostro tempo reale ed è giusto essere identificati in modo corretto in questo mondo digitale che ha le sue regole. Non possiamo pensare di gestirlo con le regole della vita reale.
Nella quotidianità viviamo ormai inconsciamente relazioni di trust ( fiducia ) . Come ci racconta ( spero di potervi linkare a breve il video dello speech ) Bruce Schneier, un “security guru”, ogni giorno quando ci alziamo ci dobbiamo fidare di chi ci ha venduto la casa, dell’ente che ha registrato la nostra proprietà, di chi ci accompagna al lavoro e quindi dell’ente che ha emesso la patente e l’ha assegnata all’autista , di chi ci ospita in albergo al quale presento a mia volta un documento che mi rappresenta e sul quale l’albergatore stesso instaura una relazione di fiducia con noi e così via sempre tutto il giorno….
Ecco questo deve accadere oggi anche su internet, e per di più deve accade in modo che siamo noi stessi come persone ( ma il discorso vale anche per l’identità aziendale e degli apparati es. IoT o smartphone ) a gestire la nostra identità ed il livello di trust con l’altra parte.
Quindi , il prossimo futuro che sta già arrivando, porterà la gestione della identità che mancava oggi ad internet.
Le parole chiavi da tenere in considerazione sono:
- SSI – Self Sovereign Identity
- DID Digital Identity Document
- ZKP Zero knowled Proof
- Blockchain e Distribuited Ledger
riassumendo il tutto in una sola INDY
Dietro a questi concetti si sta sviluppando tutto questo il nuovo Web Trust e quindi un nuovo modo di fruire internet.
Potremmo fruire dei nostri certificati digitali che ci rappresentano per chi siamo, per il lavoro che facciamo, per il conto in banca che abbiamo, oppure per la patente di guida o l’istruzione che abbiamo, gestendo noi direttamente la relazione con chi ce ne chiede la verifica, offrendo loro direttamente la dimostrazione di quello che chiedono senza fornire dati aggiuntivi o prettamente personali.
Quindi alla richiesta della verifica della maggiore età non dovremmo più fornire la nostra data di nascita ma rilasciare il nostro certificato per cui risulta che siamo maggiorenni.
Questo modo di operare porta ad eliminare il concetto di account ed a ragionare sulle connessioni in trust tra cose e servizi.
Quindi nel nuovo mondo indy avremmo un wallet che contine tutti i nostri certificati ( rilasciati dai rispettivi enti per i quali ci interessa avere prova del nostro “attributo” ) proprio come abbiamo oggi la patente, la carta di identità o la carta di credito nel nostro portafoglio.
Tali certificati li mostreremo come prova della nostra identità a chi ce lo richiede per una verifica ( claim ) senza dare più informazioni di quelle necessarie, senza che l’autorità rilasciante sappia che qualcuno ci sta chiedendo una verifica e senza che il verificante possa correlare dati in alcun modo.
La Self-Sovrin Identity è la soluzione al problema fondamentale di internet :
La Rete infatti non era stata progettata con un layer di gestione della identità.
Come si ottiene tutto questo ?
Pensiamo con concetti innovativi ovvero PUBLIC PERMISSIONED Blockchain
Per ragionare sulla nuova concezione di identità dobbiamo parlare di Public Permissioned Blockchain.
Un sistema di gestione dell’identità per internet deve essere pensato per essere pubblico nella consultazione ma privato nel gestire l’inserimento del “dato”.
Quindi la blockchain permissioned deve prevedere la Governance , per cui è previsto che qualcuno dia credito a chi partecipa alla blockchain e ne dia anche i relativi permessi e autorizzazioni.
Vi invito a leggere quanto scritto dal filosofo “John Locke” nel libro “John Locke and the Theory of Sovereignty” per capire la necessità umana del sistema proposto.
Entriamo un pò nel dettaglio.
Per affrontare nel concreto l’argomento vi devo parlare di SOVRIN.
Il progetto SOVRIN
Dato che l’implementazione maggiore ed a copertura universale per la gestione delle identità digitali passa dalla SOVRIN FOUNDATION, è necessario parlare di cosa sia SOVRIN dato che da essa derriva il contributo maggiore per quanto sotto descritto ed implementato.
La rete Sovrin rapprensenta un nuovo standard per la identità digitale ed è costruita utilizzando INDY.
La rete sovrin ha implementato tutti gli elementi sotto descritti e di cui ora vi presenterò un breve riassunto.
Innanzitutto la Blockchain Indy ( sottostante alla rete Sovrin ) ,dato che è pubblica, NON CONTIENE NESSUNA INFORMAZIONE relativa a dati PRIVATI degli utenti.
Questo nel pieno rispetto sia relativo il GDPR che di qualsiasi normativa che gestisca la privacy.
La Blockchain è utilizzata per mantenere le informazioni richieste dai proprietari della identità per transare le conferme con le terze parti nel network, ovvero DIDs
DIDs ( DIGITAL IDENTITY DOCUMENTS )
Indy è stato progettato per immagazzinare e gestire DIDs, le chiavi pubbliche a loro associate e gli endpoints di comunicazione.
I DIDs ( Digital Identity Documents ) rappresentano l’identita digitale decentralizzata come inteso e sviluppato dalla Credential Community Group del W3C
I DIDs sono pubblici o privati. I DID pubblici sono direttamente pubblicati sul ledger in modo che possano essere verificati, mentre i DID privati sono off-ledger.
Ogni DID è associato ad un DID Document ( a json file ) che contiene metadati necessari come il service endpointment, identity information, e le chiavi crittografiche.
In caso di DID Pubblico il documento puo includere il nome, l’indirizzo, il sito web ed altri dati di pubblica utilità.
Un nuovo DID di accoppiamento viene generato ogni qualvolta si instaura una relazione privata, questi vengono slavati off-ledger e criptati.
Nulla di questo è salvato sul ledger. ( rif . SOVRIN NETWORK )
SCHEMAS
In aggiunta ai PUBLIC DID sul ledger sono presenti gli SCHEMAs . Gli SCHEMAS sono la definizione di un determinato insieme di credenziali che deve essere standard per tutti, ad esempio il
passaporto. Questo insieme di dati ( SCHEMA ) che rappresenta il passaporto deve avere un numero predefinito di campi, in modo che ogni issuer ( emittente ), istituzione che rilascia il passaporto lo generi in modo che sia realizzato secondo uno standard e ne garantisca la interoperabilità world wide.
REVOCATION REGISTRY
Il ledger INDY inoltre gestisce e memorizza un Registro delle Revoche. Un metodo molto efficace per garantire la validità delle proprie credenziali. Tale registro che viene creato da chi emette le credenziali, infatti memorizza un unico numero intero che può essere utilizzado da chi vuole far valere le proprie credenziali. Tale numero lo si può inputare come elemento per una verifica ZKP.
Quindi chi deve verificare queste credenziali può utilizzare questo numero per avere conferma istantanea della veridicità e validità del documento/credenziali utilizzate.
Per revocarlo, l’ente emittente il certificato/documento dovrà solo toglierlo dal proprio registro ed aggiornare l’accumulatore cifrato. In tal modo ZKP non avrà piu validità.
Quindi per riassumere all’interno della Sovrin network ( network che utilizza Indy per la gestione delle identità World wide ) :
Sul ledger andranno :
– DIDs Pubblici ed i documenti associati ad essi con le chiavi per la verifica e gli endpoint
– Schemas e la definizione delle credenziali
– I registri di revoca
– Agent autorization policy
Mentre off-ledger:
– DIDs Privati
– Credenziali private
– Consent receipts or records of credential exchange transactions.
Schema funzionale
I DIDs sono identificatori globali univoci creati da chi li possiede senza l’ausilio di autorità centrali. Ogni DID ha associato una o piu chiavi pubbliche ( ed il proprietario del DID ne detiene le relative chiavi private) ed uno o piu endpoints , ovvero indirizzi dove il messaggio per questa identità può essere consegnato.
Un DID deve essere univocamente ( risolto come un URL ) in modo da restituire le chiavi pubbliche a lui associate ed i relativi endpoints
esempio
did:sov:3k5k2k1khr56h435g347g54
did: schema
sov: Method
3k5k2k1khr56h435g347g54: Specific identifyer
La Blockchain INDY utilizza i DIDs per stabilire le connessioni tra 2 identità , come ad esempio un utente ed il servizio web che è autorizzato ad utilizzare.
Quindi quello che ci aspettiamo è che una identità su internet avrà piu DID necessari a collegare l’utente ( uomo o macchina ) ad un altro od ad un servizio.
Per esemplificare, io utente internet che voglio avvalermi di un servizio web, genererò un DID nuovo che userò per collegarmi al servizio web ed a sua volta il servizio web genererà un DID per comunicare con me. Ognuno dei partecipanti registrerà questa relazione di DID in modo tale che se entrambe vogliono comunicare o scambiare dati tra loro devono utilizzare tali DID a loro dedicati.
Quindi ogni volta si effettua una verifica a 2 vie per autenticare utente e servizio.
Ora il problema è che per ogni “rapporto” tra “cose” su internet genererà tanti DID specifici per ogni connessione e la gestione di tutti questi collegamenti ( DIDs ) diventa difficile da gestire a mano.
Per questo di parla di Wallet e Agent. Il Wallet è un archivio che contiene tutti i DID e le informazioni private, l’Agent è un sistema software che gestisce l’interazione con le altre entità al fine di usare il DID corretto per la connessione richiesta.
Nella immagine sopra è riportato un esempio di come comunicano tra di loro gli Agent. Ci sono gli Edge Agent che sono direttamente gestiti dai proprietari, ed i Cloud Agent che facilitano lo scambio di informazioni/messaggi tra i 2 interlocutori fornendo loro degli endpoints di appoggio nel caso non siano online durante il tentativo di comunicazione.
INDY PUBLIC LEDGER
Elemento principale affinche il sistema DID esista e funzioni è rappresentato dalla blockchain che viene utilizzata com DKMS ovvero Decentralized Key Management System.
Grazie al ledger è possibile pubblicare i DID pubblici e relativi endpoints ,verificabili da chiunque in modo sicuro e non centralizzato.
Quali problemi risolve questa tecnologia:
1- L’utente definisce il proprio DID per il determinato Servizio che vuole utilizzare e lo scambia con il provider che lo vuole identificare. Questo permette di non avere un organismo centrale che gestisca questi identificatori. I DID sono controllati dall’utente.
2- Agent e Wallet funzionano come una sorta di Password manager, agevolando l’utente negli accessi ai vari servizio
3- Dato che un utente utilizza DID indipendenti per ogni servizio non è possibile correlare tali accessi per identificare l’utente tra servizi esterni ad insaputa dell’utente.
4- Dato che utente e servizio comunicano tra loro tramite DID non è necessario fornire una email cosa primaria che oggi permette di correlare i dati, piu in generale non è necessario dare altre informazioni se non necessarie a tale erogazione del servizio.
5- Il servizio stesso genera un DID per cui sono sicuro che sto usufruendo del servizio che ho scelto in quanto lo identifico con il suo DID specifico per me.
Ora ci si pone la questione come è possibile che ogni parte possa riconoscere chi ha creato e maneggia i DID con i quali ci stiamo rapportando ? Con i quali instauriamo una relazione di Trust ?
CREDENZIALI VERIFICABILI
Il progetto INDY sta sviluppando un secondo standard W3C : Verifiable Credentials ( Vcs )
Cosa intendiamo per Credenziali Verificabili ? Sono documenti come la licenza di guida, il passaporto, la laurea universitaria o la carta di identità che sono stati emessi da una specifica autorità e che sono utilizzati per dimostrare i nostri “attributi” a chi ce lo chiede.
Quindi Vcs sono l’equivalente digitale dei documenti sopra elencati, processati in modo crittografico tale per cui quando li usiamo per provare la nostra qualifica / attributo ( quindi ad esempio , l’età , il diploma o la patente di guida ) , chi li vuole verificare quanto asseriamo può essere sicuro che:
1- di chi ha emesso il “certificato” o comunque dell’attributo richiesto
2- che l’attributo è stato emesso per la identità che lo sta presentando in verifica
3- che tale attributo non è stato falsificato
4- che tale attributo non è stato revocato
Nota importante: in INDY le richieste di verifica avvengono sempre e solo tra chi detiene le VCS ( Holder of VC ) e chi le vuole verificare ( Verifier ). Non viene MAI coinvolta l’autorità che emette tali credenziali.
Questo per evitare che ad esempio il governo sappia quante volte abbiamo usato la patente per dimostrare la nostra età.
Le Verifiable Credentials sono lo specchio digitale dei documenti emessi dalle autorità nel mondo reale. Prendono dal mondo reale tale modello e lo portano nel mondo digitale in modo sicuro e affidabile
ZKP – Zero Knowledge Proof
INDY prevede delle opzioni avanzate utili alla dimostrazione delle proprie credenziali e/o attributi. In particolare un particolare attributo può essere mostrato in modo parziale, quindi fornendo indicazione di quanto richiesto in modo verificabile e veritiero senza dare informazioni ulteriori o non necessarie e dimostrare quanto richiesto.
Ad esempio se voglio dimostrare la mia maggiore età utilizzando il documento digitale che rappresenta la mia patente , quello che deve essere verificabile è solo che la mia età è maggiore dei 18 anni e non necessariamente devo dare la mia data di nascita, indirizzo, data di emissione e scadenza del mio documento.
Quello che viene riportato qui sotto ne rappresenta il concetto. A sinistra abbiamo il documento completo, a destra quello che deve risultare per chi vuole verificare la maggiore età, ovvero il risultato sarà “si è maggiorenne e questo è il suo viso” e chi lo certifica è La British Columbia.
Altro non serve per dimostrare la maggiore età.
Quindi in modo chiaro e semplice la VC ( Verifiable credentials ) dimostra a chi ha effettuato la il “claim” ovvero la richiesta di verifica della maggiore età è effettivamente corretta.
PRIVACY
Quindi il progetto Hyperledger Indy rappresenta tutto quello che ci può essere a riguardo della privacy, abbraccia tutti i principi di Privacy by Design. Riassumo qui i vari elementi cardine:
Decentralized Identifiers ( DIDs ), creati e controllati dal proprietario delle identità
L’utilizzo dei DIDs per ogni relazione ( utente – fornitore, utente – servizio ) in modo da prevenire la cross-correlazione dei dati
Peer-to-peer, end-to-end encryption dei messaggi tra mittente e destinatario
Cerifiable Credentials ( VC ) detenute dal titolare del documento digitale ed utilizzate solo quando necessario
Rivelazione selettiva dei dati , esponendo solo i dati necessari alla verificabile
L’utilizzo delle VC senza la necessità di contattare l’autorità che ha emesso le VC
Il sistema Indy si vuole posizionare come metodologia per la gestione delle identità digitali cross blockchains ed utilizzabile da qualsiasi software voglia entrare nel nuovo mondo delle identità digitali.
Bibliografia
( https://www.ernesto.net/ernesto-net-5-minute-course-on-indy-and-what-goes-on-the-blockchain-ledger/)
https://www.youtube.com/watch?v=FAskMLNwRPY
https://www.youtube.com/watch?v=oQ1TJsEppOg