Questo sito web utilizza cookie tecnici e, previo Suo consenso, cookie di profilazione, nostri e di terze parti. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsente all'uso dei cookie. Leggi la nostra Cookie Policy per esteso.OK

approcci e norme

Blockchain e identità digitale, come gestirla con i registri distribuiti

La gestione dell’identità digitale negli smart contract. La normativa di riferimento, le caratteristiche, gli approcci alla creazione e all’aggiornamento delle identità digitali e le criticità delle tecnologie basate su registri distribuiti in questo contesto

18 Mar 2019

Giovanni Manca

consulente, Anorc

Axel Mattias Ricci

blockchain developer

Matteo Vicari

blockchain developer


La gestione dell’identità digitale nella blockchain via smart contract deve necessariamente scendere a compromessi con una piena decentralizzazione: la necessità di adeguate garanzie legali delle transazioni gestite tramite smart contract sembra infatti non possa prescindere dalla presenza di terzi affidabili, soprattutto quando ci sono implicazioni fiscali.

Dopo aver scritto di ipotesi di regole per la validazione temporale degli smart contract nell’ambito di tecnologie basate su registri distribuiti esaminiamo quindi il tema della gestione dell’identità digitale negli smart contract.

Le norme in materia di smart contract e identità digitale

E’ di riferimento quanto stabilito nella conversione in legge, con modificazioni, del decreto legge 14 dicembre 2018, n. 135 recante disposizioni urgenti in materia di sostegno e semplificazione per le imprese e per la pubblica amministrazione.

In questa sede ci interessa l’articolo 8-ter, comma 2 che, per comodità, si riporta di seguito.

Art. 8-ter. (Tecnologie basate su registri distribuiti e smart contract)

2. Si definisce « smart contract » un programma per elaboratore che opera su tecnologie basate su registri distribuiti e la cui esecuzione vincola automaticamente due o più parti sulla base di effetti predefiniti dalle stesse. Gli smart contract soddisfano il requisito della forma scritta previa identificazione informatica delle parti interessate, attraverso un processo avente i requisiti fissati dall’Agenzia per l’Italia digitale con linee guida da adottare entro novanta giorni dalla data di entrata in vigore della legge di conversione del presente decreto.

In particolare è da sviluppare il principio che “gli smart contract soddisfano il requisito della forma scritta previa identificazione informatica delle parti interessate”.

Per discutere in modo consapevole di identità digitale risulta di importanza fondamentale definire l’identità digitale pubblica con attenzione alle attuali regolamentazioni europee in vigore e ai campi di applicazione dove può essere utilizzata.

Per l’Unione Europea la normativa di riferimento è il regolamento eIDAS. Operando in conformità a questo regolamento l’Italia ha ottenuto il riconoscimento del sistema SPID e ha in corso il riconoscimento della Carta d’Identità Elettronica.

Le caratteristiche dell’identità digitale

I pilastri alla base dell’idea stessa di identità di un individuo sono stati dibattuti sotto ogni punto di vista nel corso dei secoli con le accezioni filosofiche più disparate, ma giunti al mondo digitale e conseguentemente all’identità digitale è possibile riassumere una lista di caratteristiche che l’identità digitale deve possedere:

  • Accesso. L’utente deve avere accesso alla propria identità. Un utente deve essere sempre in grado di recuperare facilmente tutte le richieste e altri dati all’interno della sua identità. Non ci devono essere dati nascosti e nessun ente regolatore che ne impedisca il recupero. Ciò non significa che un utente possa necessariamente modificare tutte le affermazioni associate alla sua identità, ma implica quantomeno che dovrebbe esserne a conoscenza. Inoltre gli utenti, in generale, possano avere accesso ai solo ai propri dati.
  • Persistenza. Le identità devono essere longeve. Preferibilmente, le identità dovrebbero durare per sempre. Anche in caso di modifica dei dati di accesso alla identità o di modifica dei dati, l’identità deve persistere. Nel mondo in rapido movimento di Internet, questo obiettivo potrebbe non essere del tutto ragionevole, quindi almeno le identità dovrebbero durare fino a quando non saranno superate da nuovi sistemi di identità.
  • Trasparenza. I sistemi e gli algoritmi devono essere trasparenti. I sistemi utilizzati per amministrare e gestire una rete di identità devono essere noti, sia nel loro funzionamento che nel modo in cui sono gestiti e aggiornati. Gli algoritmi dovrebbero essere pubblicamente disponibili, open source, ben noti e il più indipendenti possibile da ogni particolare architettura; chiunque dovrebbe essere in grado di esaminare come funzionano.
  • Portabilità. Informazioni e servizi sull’identità devono essere trasportabili. Le identità non devono essere detenute da una singola entità di terze parti, anche se si tratta di un’entità fidata che si prevede lavori nel migliore interesse dell’utente. Il problema è che le entità possono scomparire – e su Internet, la maggior parte alla fine lo fa. Gli schemi possono cambiare, gli utenti possono trasferirsi in diverse giurisdizioni. Le identità trasportabili garantiscono che l’utente mantenga la propria identità indipendentemente da cause al di fuori del suo controllo e possa garantirne la persistenza nel tempo.
  • Interoperabilità. Le identità hanno poco valore se funzionano solo in nicchie applicative limitate. L’obiettivo di un sistema di identità digitale del 21° secolo è rendere le informazioni sull’identità ampiamente disponibili, superando i confini internazionali per creare identità globali.
  • Consenso. Gli utenti devono preventivamente accettare l’uso e la circolazione dei dati legati alla loro identità. Ogni sistema di identità è costruito attorno alla condivisione di tale identità e delle sue affermazioni, il che unito ad un sistema interoperabile aumenta la capillarizzazione del suo utilizzo. Tuttavia, la condivisione dei dati deve avvenire solo con il consenso dell’utente. Sebbene altri utenti, come un datore di lavoro, un ufficio di credito o un amico possano presentare reclami, l’utente deve comunque offrire il proprio consenso affinché la condivisione dei propri dati sia effettuata. Si noti che questo consenso può anche non essere esplicito, ma deve essere ancora deliberato e ben compreso.
  • Minimalizzazione. Quando vengono divulgati dati, tale divulgazione dovrebbe comprendere la quantità minima di dati necessari per svolgere l’attività in questione. Ad esempio, se è richiesta solo un’età minima, allora l’età esatta non deve essere rivelata, e se viene richiesta solo un’età, allora la data di nascita più precisa non dovrebbe essere rivelata. Questo principio può essere supportato con risposte selettive di un dato parziale in caso di interrogazioni precise al sistema e altre tecniche di “conoscenza zero”. La minimalizzazione è allo stato attuale la miglior forma di protezione della privacy individuale possibile.
  • Protezione. I diritti degli utenti devono essere protetti, anche quando questi non sono allineati, occasionalmente, con i diritti e necessità della collettività. Per garantire ciò, l’autenticazione dell’identità deve avvenire tramite algoritmi indipendenti resistenti alla censura, resistenti ad attacchi e idealmente gestiti in modo decentralizzato.

I sistemi convenzionali di gestione delle identità sono basati su strutture centralizzate ed è ben noto il ruolo dei prestatori di servizi fiduciari eIDAS e dei Gestori dell’identità SPID.

Ognuno di questi sistemi, da un punto di vista della verifica crittografica della identità, definisce la propria “trust anchor”, in altre parole le propria radice di fiducia.

Per consentire alla gestione delle identità di operare in modo inter-operabile tra tutti questi enti vengono realizzati sistemi per la gestione dell’identità federata.

Gestione decentralizzata dell’identità

La natura basilare delle tecnologie basate su Blockchain e DLT (Distributed Ledger Technologies – registri distribuiti) apre la strada a un sistema di gestione della identità del tutto decentralizzato.

La base della fiducia in questa nuova concezione non è più l’autorità centrale garante, bensì la natura decentralizzata e paritaria (nel senso dei metodi di consenso) del sistema.

Ogni possessore di una identità possiede una coppia chiave-valore con cui può essere univocamente identificato, la cui chiave indicizzata è chiamata DID, ossia Decentralized Identifier e il cui valore è invece il DDO, ossia DID Description Object.

I record sono resi sicuri con funzioni di cifratura per le quali il possessore di identità o un “guardian” (nel caso di un’identità gestita da un ente terzo) detiene le chiavi private. Una chiave pubblica corrispondente all’identità è inserita nel DDO, il quale contiene un set di dati e metodi utilizzati per interagire con il proprietario dell’identità. Seguendo i dettami di “Privacy by Design”, ogni proprietario di identità può teoricamente disporre di tutti i record DID necessari per rispettare la separazione desiderata tra identità e personalità del proprietario dell’identità a seconda del campo applicativo in cui sono utilizzati.

Per utilizzare un DID su una particolare rete DLT è necessario definirne i metodi in una specifica separata del DID, includendo l’insieme di regole che implementino il modo in cui un DID è registrato, indirizzato, aggiornato e revocato su un DLT.

Questo design elimina la dipendenza dai registri centralizzati per gli identificatori delle identità e elimina anche le autorità centrali che effettuano il key management nei modelli standard della PKI gerarchica (infrastruttura a chiave pubblica). Con i record DID su un DLT, ciascun proprietario di identità può fungere da propria autorità radice: un’architettura denominata DPKI (PKI decentralizzata).

Si noti che i metodi DID possono anche essere sviluppati per supportare e estendere le funzionalità delle identità registrate nei sistemi tradizionali. Anzi, sarebbe tecnologicamente relativamente semplice sviluppare il supporto alle DID nei sistema di identità tradizionali, creando di fatto un ponte di interoperabilità tra i mondi dell’identità centralizzata e decentralizzata.

Questo metodo ha i numeri per vedere nei DLT la sua forma più completa e efficace di realizzazione grazie ai numerosi punti in cui si vengono a completare a vicenda le necessità delle due tecnologie.

Il mondo dei DLT e delle Blockchain era “troppo anonimo”, quindi è possibile per gli utenti potranno sfruttare quelle stesse tecnologie per creare e gestire le proprie identità in rete.
Allo stesso modo le identità digitali trovano nei DLT un potente mezzo con il quale implementare un sistema decentralizzato e efficiente a servizio degli utenti della rete, dandogli un accesso disintermediato e completo alla propria identità digitale e di conseguenza della propria presenza online.

Per connettersi e interagire con la propria identità digitale inserita in un DLT è necessario passare tramite dei punti di accesso, ossia dei nodi del DLT.

Questi nodi presentano delle necessità variabili a seconda dello specifico DLT in termini di risorse di computazione e tempi di sincronizzazione.

Per esempio, ipotizzando una realizzazione basata su Bitcoin possiamo notare come sia relativamente poco oneroso eseguire e mantenere aggiornato un nodo che faccia da tramite per le transazioni necessarie all’utilizzo della propria identità digitale, mentre la stessa struttura implementata su Ethereum risulta essere più dispendiosa in termini di risorse di calcolo ma offra possibilità di utilizzare funzionalità di complesse quali Smart Contract e Dapp (applicazioni decentralizzate).

In una prima analisi la responsabilità del mantenimento del nodo connesso al DLT potrebbe essere addossata direttamente all’utente utilizzatore della identità digitale, ma questo sarebbe poco pratico per l’utente stesso, che dovrebbe aspettare lunghi tempi di sincronizzazione, impiegare risorse di calcolo e ingenti; per esempio una relativa app su dispositivi mobili si tradurrebbe in un alto consumo di batteria cosa non desiderabile da parte dell’utente.

Un’altra proposta per risolvere questa problematica prevede l’utilizzo di nodi gestiti e posseduti da terze parti a cui l’applicazione lato utente si connette per utilizzare le funzioni richieste.

In questo modo il collegamento tra utente e DLT non sarà mai diretto ma sarà sempre mediato, traducendosi in un elemento di accentramento che stona con le prerogative di architettura, altrimenti decentralizzata, oltre a creare dei single point of failure.

Creazione e aggiornamento delle identità digitali: gli approcci

Per la creazione e aggiornamento delle identità digitali esistono due tipi di approcci metodologici che vengono descritti brevemente di seguito.

  • Il primo metodo prevede che la persona richieda in prima battuta una certificazione digitale a un ente centrale offerente quel servizio e riconosciuto a livello legale.
    Questo ovviamente introduce un elemento di “trust” in un ambiente comunemente considerato decentralizzato come la DLT.

Se da un punto di vista legale questo consente maggiore riconoscimento come uno strumento certificato, dall’altro costituisce una limitazione alle caratteristiche ricercate che tutti i sistemi di identità digitale non dovrebbero possedere (sopra elencate), quali per esempio un accentramento potenzialmente troppo marcato e invadente del controllo del sistema nelle mani di attori statali nazionali o internazionali.
Le implementazioni tecnologiche di questo metodo soddisfano i criteri minimi necessari per essere conformi alle specifiche regole del regolamento eIDAS europea, e vari Stati membri dell’UE hanno provveduto a rilasciare appositi strumenti certificatori, come ad esempio, lo SPID italiano (Sistema Pubblico di Identità Digitale).

  • Il secondo prevede che la persona auto certifichi la propria identità quindi la definizione di un sistema basato sul concetto di Self-Sovereign Identity: l’utente deve essere centrale nell’amministrazione dell’identità, lasciando di fatto totale autonomia all’utente nella creazione e aggiornamento di ogni caratteristica della propria identità. Per realizzare appieno questo approccio è assolutamente necessaria la portabilità e l’interoperabilità dell’identità digitale dell’utente, il quale potrebbe godere appieno dei vantaggi della propria identità digitale in più postazioni e con tutti i tipi di sistema software preesistenti.

A differenza dell’altro approccio questo sfrutta appieno le possibilità offerte dai DLT permissionless in quanto non introduce nessun elemento di centralizzazione, rendendo questo sistema completamente trustless e resistente alla censura, dando così all’utente il controllo della propria presenza in rete ; l’altra faccia della medaglia e che si impatta con una bassa certificazione legale, in quanto l’autocertificazione non può soddisfare i requisiti per la gestione di un elemento così importante per uno stato quali le identità.

Le criticità

I DLT non possono nulla contro un utente che inserisce dati falsi, e anzi in questa caratteristica risiede la più grande criticità dei DLT, che però risulta essere insormontabile a causa del principio fondante a meno di non snaturarlo completamente.

E’ rilevante notare che entrambi questi approcci siano validi e che sono stati testati in vari progetti, ma che allo stato attuale essi siano limitati a dei campi applicativi precisi, caratteristica che probabilmente sfumerà nel prossimo futuro quando saranno messe in campo nuove tecnologie di supporto in questo ambito, quali per esempio lo sviluppo di dispositivi “oracoli” (gestori degli eventi nei flussi operativi degli smart contract) e il miglioramento degli algoritmi esistenti di deep learning e quindi di utilizzo dell’intelligenza artificiale.

Infine molti dei requisiti di base richiedono sviluppo di adeguati standard soprattutto per l’interoperabilità, a meno di non regolamentare dei DLT “statali” ovvero una cosa che non ha bisogno di DLT.

_________________________________________________________

Per il lettore che vuole approfondire si riportano alcuni studi e lavori scientifici sui temi del presente articolo.

Francesco Buccafurri, Gianluca Lax, Antonia Russo, and Guillaume Zunino

Integrating Digital Identity and Blockchain.

In questo lavoro scientifico si ipotizza un legame tra SPID e un’architettura blockchain.

Il contatto del Professor Buccafurri citato nel paper è bucca@unirc.it .

Accord Project ID: The Smart Legal Contract Identity and Trust Framework Standard

Open Identity Exchange

https://www.openidentityexchange.org/bitgov/wp-content/uploads/2018/05/Accord-Project-ID-The-Smart-Legal-Contracts-Identity-and-Trust-Framework-Standard-FINAL1.pdf

Drummond Reed, Les Chasen, Christopher Allen, Ryan Grant

DID (Decentralized Identifier) Data Model and Generic Syntax 1.0

https://github.com/WebOfTrustInfo/rwot3-sf/blob/master/draft-documents/DID-Spec-Implementers-Draft-01.pdf

Christopher Allen

The Path to Self-Sovereign Identity

http://www.lifewithalacrity.com/previous/

A distributed digital identity system with a marketplace for verifiable claims

SpidChain

https://drive.google.com/file/d/0B89WE3IIHmy1Z0ZSSWVmVEtaaG8/view

@RIPRODUZIONE RISERVATA

Articolo 1 di 4