Chapter 3
Obiettivi Formativi:
- Come viene costruita una credenziale verificabile e quali sono le sue proprietà principali e fondamentali.
- Come può una credenziale verificabile garantire standard sicuri e scalabili tramite le sue proprietà
- Come può una credenziale verificabile soddisfare livelli di privacy e sicurezza
- Qual è lo stato dell’arte dalle credenziali verificabili e Self-Sovreign Identity nel confine normativo europeo
Chapter 3
Obiettivi Formativi:
- Come viene costruita una credenziale verificabile e quali sono le sue proprietà principali e fondamentali.
- Come può una credenziale verificabile garantire standard sicuri e scalabili tramite le sue proprietà
- Come può una credenziale verificabile soddisfare livelli di privacy e sicurezza
- Qual è lo stato dell’arte dalle credenziali verificabili e Self-Sovreign Identity nel confine normativo europeo
Concetti base delle credenziali verificabili
Quando due software scambiano dei dati, è necessario che essi utilizzino una terminologia che entrambi capiscano. Il primo elemento che troviamo all’interno di una credenziale verificabile è quindi il contesto della conversazione.
Le credenziali verificabili e le presentazioni hanno diversi attributi e valori che sono identificati dagli URI. Questa specificazione, usando la proprietà “@context”, mappando gli URI richiesti da specifiche credenziali e presentazioni.
L’esempio qui sopra mostra il contesto base URI (https://www.w3.org/2018/credentials/v1), un documento DID, per stabilire che la conversazione verte sulla credenziale verificabile. Il secondo URI (https://www.w3.org/2018/credentials/examples/v1) stabilisce che la conversazione riguarda nello specifico “examples”.
Concetti base delle credenziali verificabili
Quando due software scambiano dei dati, è necessario che essi utilizzino una terminologia che entrambi capiscano. Il primo elemento che troviamo all’interno di una credenziale verificabile è quindi il contesto della conversazione.
Le credenziali verificabili e le presentazioni hanno diversi attributi e valori che sono identificati dagli URI. Questa specificazione, usando la proprietà “@context”, mappando gli URI richiesti da specifiche credenziali e presentazioni.
L’esempio qui sopra mostra il contesto base URI (https://www.w3.org/2018/credentials/v1), un documento DID, per stabilire che la conversazione verte sulla credenziale verificabile. Il secondo URI (https://www.w3.org/2018/credentials/examples/v1) stabilisce che la conversazione riguarda nello specifico “examples”.
IDENTIFICATORI
Per esprimere affermazioni verso di un soggetto specifico, viene utilizzato una tipologia di identificatore che aiuta tutte le entità coinvolte ad identificare ed esprimersi riguardo il medesimo soggeto in maniera precisa.
Si introduce quindi la proprietà “id”. Quest’ultima ha quindi lo scopo di riferirsi inequivocabilmente ad un oggetto, una persona, un prodotto, un’organizzazione. Utilizzando questa proprietà si permette l’espressione di affermazioni riguardo ad uno specifico argomento della credenziale verificabile. Solitamente è un identificatore decentralizzato. (DID)
Se la proprietà “id” è presente:
- La proprietà “id” DEVE esprimere un identificatore che gli altri probabilmente utilizzeranno per esporre affermazioni riguardo una specifica caratteristica identificata dall’identificatore;
- La proprietà “id” NON DEVE avere più di un valore;
- Il valore della proprietà “id” DEVE essere un URI.
L’esempio qui in basso utilizza due tipi di identificatori:
- il primo è per la credenziale verificabile ed utilizza un URL http.
- Il secondo identificatore è per il soggetto della credenziale e utilizza un identificatore decentralizzato, il DID.
TYPES
I software processano gli oggetti specificati nel documento visualizzano la proprietà “type” per determinare se una credenziale fornita sia appropriata o meno. La proprietà “type”, in altre parole, identifica l’oggetto della credenziale.
Le credenziali e le presentazioni verificabili DEVONO avere la proprietà “type”. Qualunque credenziale o presentazione sprovvista risulta non verificabile.
Per esempio, l’oggetto di una credenziale con il “type” UniversityDegreeCredential comunica al verificatore che l’oggetto associato alla proprietà “soggetto della credenziale” contiene l’identificatore del:
- Soggetto della proprietà “id”.
- Tipologia di diploma nella proprietà “type”
- Titolo del diploma nella proprietà “nome”
IDENTIFICATORI
Per esprimere affermazioni verso di un soggetto specifico, viene utilizzato una tipologia di identificatore che aiuta tutte le entità coinvolte ad identificare ed esprimersi riguardo il medesimo soggeto in maniera precisa.
Si introduce quindi la proprietà “id”. Quest’ultima ha quindi lo scopo di riferirsi inequivocabilmente ad un oggetto, una persona, un prodotto, un’organizzazione. Utilizzando questa proprietà si permette l’espressione di affermazioni riguardo ad uno specifico argomento della credenziale verificabile. Solitamente è un identificatore decentralizzato. (DID)
Se la proprietà “id” è presente:
- La proprietà “id” DEVE esprimere un identificatore che gli altri probabilmente utilizzeranno per esporre affermazioni riguardo una specifica caratteristica identificata dall’identificatore;
- La proprietà “id” NON DEVE avere più di un valore;
- Il valore della proprietà “id” DEVE essere un URI.
L’esempio qui in basso utilizza due tipi di identificatori:
- il primo è per la credenziale verificabile ed utilizza un URL http.
- Il secondo identificatore è per il soggetto della credenziale e utilizza un identificatore decentralizzato, il DID.
TYPES
I software processano gli oggetti specificati nel documento visualizzano la proprietà “type” per determinare se una credenziale fornita sia appropriata o meno. La proprietà “type”, in altre parole, identifica l’oggetto della credenziale.
Le credenziali e le presentazioni verificabili DEVONO avere la proprietà “type”. Qualunque credenziale o presentazione sprovvista risulta non verificabile.
Per esempio, l’oggetto di una credenziale con il “type” UniversityDegreeCredential comunica al verificatore che l’oggetto associato alla proprietà “soggetto della credenziale” contiene l’identificatore del:
- Soggetto della proprietà “id”.
- Tipologia di diploma nella proprietà “type”
- Titolo del diploma nella proprietà “nome”
SOGGETTO DELLA CREDENZIALE
Una credenziale verificabile contiene affermazioni riguardanti uno o più soggetti. Questa specificazione definisce la proprietà “credentialSubject”.
Una credenziale verificabile DEVE avere la proprietà “credentialSubject”. Il valore di questa proprietà è definito da un set di oggetti che contengono una o più caratteristiche riferite al soggetto della credenziale
In una credenziale è possibile esprimere informazioni riguardanti più soggetti, ad esempio marito e moglie.
È possibile esprimere informazioni relative a più soggetti in una credenziale verificabile. L’esempio seguente specifica due soggetti che sono coniugi. Si noti l’uso della notazione di matrice per associare più soggetti alla proprietà credentialSubject.
EMITTENTE
La credenziale verificabile DEVE avere la proprietà “issuer”.
Il valore della proprietà “issuer” DEVE essere un URI o un oggetto contenente la proprietà “id” ed è inoltre consigliato che l’URI risulti in un documento contenente informazioni riguardanti l’emittente che possano essere utilizzate per verificare la credenziale.
Rimane possibile esprimere informazioni aggiuntive riguardo l’emittente associando un oggetto alla proprietà “issuer”.
SOGGETTO DELLA CREDENZIALE
Una credenziale verificabile contiene affermazioni riguardanti uno o più soggetti. Questa specificazione definisce la proprietà “credentialSubject”.
Una credenziale verificabile DEVE avere la proprietà “credentialSubject”. Il valore di questa proprietà è definito da un set di oggetti che contengono una o più caratteristiche riferite al soggetto della credenziale
In una credenziale è possibile esprimere informazioni riguardanti più soggetti, ad esempio marito e moglie.
È possibile esprimere informazioni relative a più soggetti in una credenziale verificabile. L’esempio seguente specifica due soggetti che sono coniugi. Si noti l’uso della notazione di matrice per associare più soggetti alla proprietà credentialSubject.
EMITTENTE
La credenziale verificabile DEVE avere la proprietà “issuer”.
Il valore della proprietà “issuer” DEVE essere un URI o un oggetto contenente la proprietà “id” ed è inoltre consigliato che l’URI risulti in un documento contenente informazioni riguardanti l’emittente che possano essere utilizzate per verificare la credenziale.
Rimane possibile esprimere informazioni aggiuntive riguardo l’emittente associando un oggetto alla proprietà “issuer”.
DATA DI EMISSIONE
La proprietà “issuanceDate” esprime la data e l’ora in cui una credenziale diventa valida.
La credenziale DEVE avere la proprietà “issuanceDate”. Il valore di tale proprietà deve essere una stringa di valori che comprende data e ora. Il tempo indicato nella stringa definisce il momento in cui l’informazione associata al soggetto della credenziale diventa valida.
DATA DI SCADENZA
La proprietà “expirationDate” definisce la data di scadenza dell’informazione contenuta nella credenziale.
Se presente, essa DEVE essere una stringa di valori comprendente data e ora indicante il momento esatto in cui la credenziale cessa di essere valida.
DATA DI EMISSIONE
La proprietà “issuanceDate” esprime la data e l’ora in cui una credenziale diventa valida.
La credenziale DEVE avere la proprietà “issuanceDate”. Il valore di tale proprietà deve essere una stringa di valori che comprende data e ora. Il tempo indicato nella stringa definisce il momento in cui l’informazione associata al soggetto della credenziale diventa valida.
DATA DI SCADENZA
La proprietà “expirationDate” definisce la data di scadenza dell’informazione contenuta nella credenziale.
Se presente, essa DEVE essere una stringa di valori comprendente data e ora indicante il momento esatto in cui la credenziale cessa di essere valida.
PROVE (Proof)
Almeno un meccanismo di convalida e i dettagli necessari per valutare tali prove DEVONO essere espressi per una credenziale o una presentazione per renderla verificabile.
Si individuano due diversi meccanismi: uno esterno e uno integrato. Il meccanismo esterno rappresenta l’espressione di questo modello di dati, come il token Web JSON. Nel meccanismo integrato, invece, la prova è inclusa nei dati come una Firma dei Dati Collegati.
È possibile utilizzare una o più prove crittografiche per rilevare la manomissione e verificare l’autorità di una credenziale. Il metodo specifico utilizzato DEVE essere specificato utilizzando la proprietà “type”.
Se per il meccanismo di convalida viene utilizzata una firma digitale, la proprietà “proof” deve contenere il nome del firmatario, un riferimento e la data in cui ha firmato.
STATO
La proprietà “credentialStatus” definisce lo stato corrente di una credenziale, come ad esempio lo stato di sospensione o revoca.
Tale proprietà DEVE contenere:
- la proprietà “id”, in forma URL.
- la proprietà “type”, che esprime lo stato corrente della credenziale.
Ci si aspetta che tale valore fornisca abbastanza informazioni per determinare lo stato corrente. Ad esempio l’oggetto può contenere un link di un documento esterno attestante la sospensione o revoca della credenziale.
Le revoche possono essere inserite all’interno di una blockchain o un registro distribuito, da agevolare colui che verifica la tipologia di revoca o i termini di essa, consultando un root of trust solido ed non manomettibile.
PROVE (Proof)
Almeno un meccanismo di convalida e i dettagli necessari per valutare tali prove DEVONO essere espressi per una credenziale o una presentazione per renderla verificabile.
Si individuano due diversi meccanismi: uno esterno e uno integrato. Il meccanismo esterno rappresenta l’espressione di questo modello di dati, come il token Web JSON. Nel meccanismo integrato, invece, la prova è inclusa nei dati come una Firma dei Dati Collegati.
È possibile utilizzare una o più prove crittografiche per rilevare la manomissione e verificare l’autorità di una credenziale. Il metodo specifico utilizzato DEVE essere specificato utilizzando la proprietà “type”.
Se per il meccanismo di convalida viene utilizzata una firma digitale, la proprietà “proof” deve contenere il nome del firmatario, un riferimento e la data in cui ha firmato.
STATO
La proprietà “credentialStatus” definisce lo stato corrente di una credenziale, come ad esempio lo stato di sospensione o revoca.
Tale proprietà DEVE contenere:
- la proprietà “id”, in forma URL.
- la proprietà “type”, che esprime lo stato corrente della credenziale.
Ci si aspetta che tale valore fornisca abbastanza informazioni per determinare lo stato corrente. Ad esempio l’oggetto può contenere un link di un documento esterno attestante la sospensione o revoca della credenziale.
Le revoche possono essere inserite all’interno di una blockchain o un registro distribuito, da agevolare colui che verifica la tipologia di revoca o i termini di essa, consultando un root of trust solido ed non manomettibile.
PRESENTAZIONE
Le presentazioni verificabili vengono utilizzate per combinare e presentare le credenziali. Possono inoltre essere “confezionate” in modo tale da dimostrare l’autorevolezza del dato. I dati nelle presentazioni sono solitamente riferiti al medesimo soggetto, ma non vi è un limite di soggetti che possono essere inclusi. L’aggregazione di informazioni derivanti da diverse credenziali rappresenta l’uso più comune delle presentazioni.
La presentazione verificabile è solitamente composta dalle seguenti proprietà:
- id: la proprietà “id” è facoltativa e può essere utilizzata per fornire un identificatore unico per la presentazione.
- type: la proprietà “type” è richiesta ed esprime il tipo di presentazione, ad esempio VerifiablePresentation.
- Credenziale verificabile: se presente, il valore di questa proprietà DEVE essere costruito da una o più credenziali, o da dati derivanti da credenziali verificabili in un formato crittograficamente verificabile.
- possessore: se presente, il valore associato è un URI riferito all’entità che ha generato la presentazione.
- prova: se presente, il valore di questa proprietà assicura la verificabilità della presentazione.
PRESENTAZIONE
Le presentazioni verificabili vengono utilizzate per combinare e presentare le credenziali. Possono inoltre essere “confezionate” in modo tale da dimostrare l’autorevolezza del dato. I dati nelle presentazioni sono solitamente riferiti al medesimo soggetto, ma non vi è un limite di soggetti che possono essere inclusi. L’aggregazione di informazioni derivanti da diverse credenziali rappresenta l’uso più comune delle presentazioni.
La presentazione verificabile è solitamente composta dalle seguenti proprietà:
- id: la proprietà “id” è facoltativa e può essere utilizzata per fornire un identificatore unico per la presentazione.
- type: la proprietà “type” è richiesta ed esprime il tipo di presentazione, ad esempio VerifiablePresentation.
- Credenziale verificabile: se presente, il valore di questa proprietà DEVE essere costruito da una o più credenziali, o da dati derivanti da credenziali verificabili in un formato crittograficamente verificabile.
- possessore: se presente, il valore associato è un URI riferito all’entità che ha generato la presentazione.
- prova: se presente, il valore di questa proprietà assicura la verificabilità della presentazione.
Concetti avanzati delle credenziali verificabili
La sequenza più comune di azioni fatta dagli attori nel processo di autorizzazione e/o identificazione è concepita come di seguito:
- L’emittente emette la credenziale al possessore.
- Il possessore porge la credenziale al verificatore o al root of trust
- Il verificatore o sul root of trust /si verifica la credenziale.
Tuttavia, tutte tipologie di credenziali che possono essere utilizzate dall’utente in rete devono soddisfare alcuni criteri e avere alcune caratterustiche che garantiscono interoperabilità, scalabilità e sicurezza.
Andiamo a scoprire quali:
Concetti avanzati delle credenziali verificabili
La sequenza più comune di azioni fatta dagli attori nel processo di autorizzazione e/o identificazione è concepita come di seguito:
- L’emittente emette la credenziale al possessore.
- Il possessore porge la credenziale al verificatore o al root of trust
- Il verificatore o sul root of trust /si verifica la credenziale.
Tuttavia, tutte tipologie di credenziali che possono essere utilizzate dall’utente in rete devono soddisfare alcuni criteri e avere alcune caratterustiche che garantiscono interoperabilità, scalabilità e sicurezza.
Andiamo a scoprire quali:
ESTENDIBILITÀ
Uno degli obiettivi del modello è quello di abilitare l’innovazione senza autorizzazioni. Questo approccio è comunemente chiamato “assunto open world”: ogni entità può fare affermazioni riguardo qualsiasi altra entità.
Assumiamo che uno sviluppatore voglia estendere la credenziale con altri due pezzi di informazione: un numero identificativo e il cibo preferito. La prima cosa da fare è creare un contesto JSON-LD contenente i due nuovi termini, come mostrato qui sotto.
Dopo questo passaggio, lo sviluppatore pubblica il documento cosicché i verificatori possano appunto verificare la credenziale. Assumendo che il contesto JSON-LD venga pubblicato in https://example.com/contexts/mycontext.jsonld, possiamo ora estendere questo esempio includendo il contesto e aggiungendo le due nuove proprietà alla credenziale verificabile.
CONTESTAZIONI
Esistono almeno due casi da considerare in cui un’entità voglia contestare una credenziale emessa:
- Un soggetto contesta un’affermazione fatta dall’emittente. Ad esempio la proprietà “indirizzo” è incorretta.
- Un entità contesta una potenziale falsa affermazione fatta dall’emittente. Ad esempio un soggetto terzo, “impostore”, afferma il numero identificativo di un’entità.
Il meccanismo di emissioni di una DisputeCredential è il medesimo di quello di una credenziale corretta eccetto per l’dentificatore del credentialSubject nella proprietà DisputeCredential che invece è quello della credenziale contestata.
Ad esempio se una credenziale con identificatore https://example.org/credentials/245 è contestata, il soggetto può emettere una credenziale come quella nell’immagine sottostante e presentarla al verificatore insieme alla credenziale contestata.
ESTENDIBILITÀ
Uno degli obiettivi del modello è quello di abilitare l’innovazione senza autorizzazioni. Questo approccio è comunemente chiamato “assunto open world”: ogni entità può fare affermazioni riguardo qualsiasi altra entità.
Assumiamo che uno sviluppatore voglia estendere la credenziale con altri due pezzi di informazione: un numero identificativo e il cibo preferito. La prima cosa da fare è creare un contesto JSON-LD contenente i due nuovi termini, come mostrato qui sotto.
Dopo questo passaggio, lo sviluppatore pubblica il documento cosicché i verificatori possano appunto verificare la credenziale. Assumendo che il contesto JSON-LD venga pubblicato in https://example.com/contexts/mycontext.jsonld, possiamo ora estendere questo esempio includendo il contesto e aggiungendo le due nuove proprietà alla credenziale verificabile.
CONTESTAZIONI
Esistono almeno due casi da considerare in cui un’entità voglia contestare una credenziale emessa:
- Un soggetto contesta un’affermazione fatta dall’emittente. Ad esempio la proprietà “indirizzo” è incorretta.
- Un entità contesta una potenziale falsa affermazione fatta dall’emittente. Ad esempio un soggetto terzo, “impostore”, afferma il numero identificativo di un’entità.
Il meccanismo di emissioni di una DisputeCredential è il medesimo di quello di una credenziale corretta eccetto per l’dentificatore del credentialSubject nella proprietà DisputeCredential che invece è quello della credenziale contestata.
Ad esempio se una credenziale con identificatore https://example.org/credentials/245 è contestata, il soggetto può emettere una credenziale come quella nell’immagine sottostante e presentarla al verificatore insieme alla credenziale contestata.
TERMINI D’USO
I termini d’uso sono utilizzati dall’emittente o dal possessore per comunicare i termini sotto i quali la credenziale o la presentazione è stata emessa. L’emittente include i termini nella credenziale verificabile, mentre il possessore li colloca all’interno della presentazione verificabile.
Il valore di questa proprietà informa il verificatore quali azioni è obbligato a fare, quali non sono permesse e quali invece sono concesse.
Nell’esempio qui basso, l’emittente proibisce al verificatore l’archiviazione dei dati forniti.
REFRESHING
Risulta utile inoltre abilitare un sistema di refresh, manuale o automatico, della credenziale scaduta. Questa specificazione definisce la proprietà “refreshService”, che abilita l’emittente ad includere un link per il servizio di refreshing.
Tale servizio viene utilizzato principalmente quando la credenziale risulta scaduta oppure quando l’emittente non pubblica lo stato dell’informazione.
TERMINI D’USO
I termini d’uso sono utilizzati dall’emittente o dal possessore per comunicare i termini sotto i quali la credenziale o la presentazione è stata emessa. L’emittente include i termini nella credenziale verificabile, mentre il possessore li colloca all’interno della presentazione verificabile.
Il valore di questa proprietà informa il verificatore quali azioni è obbligato a fare, quali non sono permesse e quali invece sono concesse.
Nell’esempio qui basso, l’emittente proibisce al verificatore l’archiviazione dei dati forniti.
REFRESHING
Risulta utile inoltre abilitare un sistema di refresh, manuale o automatico, della credenziale scaduta. Questa specificazione definisce la proprietà “refreshService”, che abilita l’emittente ad includere un link per il servizio di refreshing.
Tale servizio viene utilizzato principalmente quando la credenziale risulta scaduta oppure quando l’emittente non pubblica lo stato dell’informazione.
SCHEMA DI DATI
Gli schemi sono utili per rinforzare una specifica struttura riferita ad una determinata raccolta di dati. Esistono almeno due tipi di schemi:
- Schema di convalida dei dati, che è utilizzato per verificare che la struttura ed il contenuto di una credenziale siano conformi allo schema pubblicato.
- Schema di codifica dei dati, utilizzato per mappare il contenuto di una credenziale in un altro formato, come ad esempio il formato binario usato per la prova zero-knowledge.
Vediamo l’utilizzo della proprietà “credentialSchema” per permettere la validazione dello schema JSON:
Nell’esempio, l’emittente sta specificando un credentialSchema, che indica un file [JSON-SCHEMA-2018] il quale può essere utilizzato dal verificatore per determinare se la credenziale verificabile è ben costruita.
L’utilizzo della della proprietà “credentialSchema” permettere la validazione tramite il meccanismo critografico zero-knowledge.
Nell’esempio, l’emittente specifica un credentialSchema indicante un formato di dati binario zero-knowledge capace di trasformare un input di dati in un formato utilizzabile dal verificatore per determinare se la prova fornita con la credenziale risulta valida.
SCHEMA DI DATI
Gli schemi sono utili per rinforzare una specifica struttura riferita ad una determinata raccolta di dati. Esistono almeno due tipi di schemi:
- Schema di convalida dei dati, che è utilizzato per verificare che la struttura ed il contenuto di una credenziale siano conformi allo schema pubblicato.
- Schema di codifica dei dati, utilizzato per mappare il contenuto di una credenziale in un altro formato, come ad esempio il formato binario usato per la prova zero-knowledge.
Vediamo l’utilizzo della proprietà “credentialSchema” per permettere la validazione dello schema JSON:
Nell’esempio, l’emittente sta specificando un credentialSchema, che indica un file [JSON-SCHEMA-2018] il quale può essere utilizzato dal verificatore per determinare se la credenziale verificabile è ben costruita.
L’utilizzo della della proprietà “credentialSchema” permettere la validazione tramite il meccanismo critografico zero-knowledge.
Nell’esempio, l’emittente specifica un credentialSchema indicante un formato di dati binario zero-knowledge capace di trasformare un input di dati in un formato utilizzabile dal verificatore per determinare se la prova fornita con la credenziale risulta valida.
PROVE ZERO-KNOWLEDGE
Una prova zero-knowledge è un metodo crittografico in cui un’entità può provare ad un’altra entità di conoscere un determinato valore senza rivelare il valore effettivo. Ad esempio può provare che un’università ha emesso un diploma a Tom senza rivelare l’identità del ragazzo o qualsiasi altra informazione riconducibile alla sua persona contenuta nel diploma stesso.
Le abilità chiave del possessore della credenziale introdotte da tale meccanismo sono:
- Combinare credenziali diverse, emesse da diversi emittenti in una singola presentazione senza rivelare la credenziale o il soggetto al verificatore.
- Scegliere accuratamente delle informazioni presenti nella credenziale da fornire al verificatore.
- Produrre una credenziale derivata che abbia un formato compatibile allo schema utilizzato dal verificatore , senza la necessità di coinvolgere l’emittente.
Per utilizzare credenziali zero-knowledge, l’emittente deve emettere una credenziale tale per cui il possessore sia in grado di presentare le informazioni al verificatore, mantenendo un determinato livello di privacy.
A tal fine sono fondamentali due requisiti che una credenziale DEVE contenere:
- Un modello di credenziale, utilizzando la proprietà “credentialSchema”, che può essere utilizzata da tutte le entità per eseguire operazioni zero-knowledge.
- Una prova, utilizzando la proprietà “proof”, utilizzabile per ricavare presentazioni verificabili deve informazioni presenti nella credenziale originale zero-knowledge. Tuttavia, la presentazione non deve rivelare informazioni che il possessore non ha intenzione di rivelare.
PROVE ZERO-KNOWLEDGE
Una prova zero-knowledge è un metodo crittografico in cui un’entità può provare ad un’altra entità di conoscere un determinato valore senza rivelare il valore effettivo. Ad esempio può provare che un’università ha emesso un diploma a Tom senza rivelare l’identità del ragazzo o qualsiasi altra informazione riconducibile alla sua persona contenuta nel diploma stesso.
Le abilità chiave del possessore della credenziale introdotte da tale meccanismo sono:
- Combinare credenziali diverse, emesse da diversi emittenti in una singola presentazione senza rivelare la credenziale o il soggetto al verificatore.
- Scegliere accuratamente delle informazioni presenti nella credenziale da fornire al verificatore.
- Produrre una credenziale derivata che abbia un formato compatibile allo schema utilizzato dal verificatore , senza la necessità di coinvolgere l’emittente.
Per utilizzare credenziali zero-knowledge, l’emittente deve emettere una credenziale tale per cui il possessore sia in grado di presentare le informazioni al verificatore, mantenendo un determinato livello di privacy.
A tal fine sono fondamentali due requisiti che una credenziale DEVE contenere:
- Un modello di credenziale, utilizzando la proprietà “credentialSchema”, che può essere utilizzata da tutte le entità per eseguire operazioni zero-knowledge.
- Una prova, utilizzando la proprietà “proof”, utilizzabile per ricavare presentazioni verificabili deve informazioni presenti nella credenziale originale zero-knowledge. Tuttavia, la presentazione non deve rivelare informazioni che il possessore non ha intenzione di rivelare.
Considerazioni di sicurezza e privacy
Le persone hanno differenti livelli di comfort riguardo alle informazioni che sono disposti a fornire e alle informazioni che possono essere ricavate dai dati forniti.
Perciò non esiste un univoco approccio che funzioni in tutti i casi, le soluzioni di privacy si differenziano per ciascun caso.
Considerazioni di sicurezza e privacy
Le persone hanno differenti livelli di comfort riguardo alle informazioni che sono disposti a fornire e alle informazioni che possono essere ricavate dai dati forniti.
Perciò non esiste un univoco approccio che funzioni in tutti i casi, le soluzioni di privacy si differenziano per ciascun caso.
Informazioni che identificano una persona
I dati associati alla credenziale verificabile archiviati nel campo credential.credentialSubject sono suscettibili di violazioni della privacy quando vengono condivise con i verificatori. I dati personali, come ad esempio il numero della carta d’identità, l’indirizzo, il nome completo, possono essere facilmente utilizzati per determinare, tracciare e correlare un’entità.
Correlazione Identifier-Based
I soggetti della credenziale sono identificati utilizzando il campo credential.credentialSubject.id. Gli identificatori utilizzati per identificare un soggetto creano un grande rischio di correlazione quando essi stessi sono di lunga data o utilizzati più volte.
Siccome le proprietà anti-correlazione sono un requisito fondamentale all’interno del sistema della credenziale verificabile, è fortemente consigliato che gli identificatori siano:
- Legati ad un’unica origine
- Abbiano un utilizzo singolo (monouso)
- Sostituiti da token nuovi con monoutilizzo.
Informazioni che identificano una persona
I dati associati alla credenziale verificabile archiviati nel campo credential.credentialSubject sono suscettibili di violazioni della privacy quando vengono condivise con i verificatori. I dati personali, come ad esempio il numero della carta d’identità, l’indirizzo, il nome completo, possono essere facilmente utilizzati per determinare, tracciare e correlare un’entità.
Correlazione Identifier-Based
I soggetti della credenziale sono identificati utilizzando il campo credential.credentialSubject.id. Gli identificatori utilizzati per identificare un soggetto creano un grande rischio di correlazione quando essi stessi sono di lunga data o utilizzati più volte.
Siccome le proprietà anti-correlazione sono un requisito fondamentale all’interno del sistema della credenziale verificabile, è fortemente consigliato che gli identificatori siano:
- Legati ad un’unica origine
- Abbiano un utilizzo singolo (monouso)
- Sostituiti da token nuovi con monoutilizzo.
Correlazione Signature-Based
Se anche in questo caso è fondamentale mantenere un elevato grado di anti-correlazione, è consigliato che le firme apportate alle credenziali siano rigenerate ogni volta utilizzando tecnologie come prove zero-knowledge, firme di gruppo, ecc.
Principio della minimizzazione dei dati
Con le presentazioni verificabili, la minimizzazione dei dati per gli emittenti significa limitare il contenuto di una credenziale “al minimo richiesto” dall’utilizzo che ne farà il verificatore. Per i verificatori, tale approccio si identifica nella limitazione delle informazioni richieste per un determinato scopo o l’accesso a determinati servizi.
I verificatori sono sollecitati a richiedere solamente le informazioni che sono assolutamente necessarie per una transazione. Questo è importante per almeno due ragioni:
- Ridurre la responsabilità del verificatore che gestisce informazioni sensibili e di cui non ha bisogno.
- Aumenta la privacy dell’individuo semplicemente richiedendo informazioni richieste per una transazione specifica.
Correlazione Signature-Based
Se anche in questo caso è fondamentale mantenere un elevato grado di anti-correlazione, è consigliato che le firme apportate alle credenziali siano rigenerate ogni volta utilizzando tecnologie come prove zero-knowledge, firme di gruppo, ecc.
Principio della minimizzazione dei dati
Con le presentazioni verificabili, la minimizzazione dei dati per gli emittenti significa limitare il contenuto di una credenziale “al minimo richiesto” dall’utilizzo che ne farà il verificatore. Per i verificatori, tale approccio si identifica nella limitazione delle informazioni richieste per un determinato scopo o l’accesso a determinati servizi.
I verificatori sono sollecitati a richiedere solamente le informazioni che sono assolutamente necessarie per una transazione. Questo è importante per almeno due ragioni:
- Ridurre la responsabilità del verificatore che gestisce informazioni sensibili e di cui non ha bisogno.
- Aumenta la privacy dell’individuo semplicemente richiedendo informazioni richieste per una transazione specifica.
Credenziali al portatore
Una credenziale al portatore è un’informazione che favorisce la privacy, come un ticket di un concerto, che dà il diritto al possessore di godere di tale risorsa senza rivelare informazioni sensibili del possessore stesso. Sono spesso utilizzate in casi a basso rischio dove la condivisione di credenziali non implica perdite economiche o reputazionali. Esse devono essere create attentamente per far sì che non possano divulgare accidentalmente più informazioni di quelle richieste. L’utilizzo di queste credenziali in più siti differenti crea un elevato rischio di correlazione.
Gli emittenti delle credenziali al portatore devono assicurare che le credenziali portino benefici in tema di privacy, ovvero:
- Monouso, ove possibile
- Non contengono informazioni personali
- Non sono eccessivamente correlabili.
I possessori devono essere avvertiti dal proprio software qualora la propria credenziale contenente informazioni sensibili sia emessa o richiesta, oppure qualora vi sia rischio di correlazione quando il soggetto unisce due credenziali di questa tipologia.
Controlli di validità
Quando processano le credenziali verificabili, i verificatori devono eseguire diversi controlli di validità:
- Lo stato di abilitazione professionale del possessore.
- Data di rinnovo o revoca della licenza.
- Requisiti di un individuo.
- L’esistenza di una relazione tra il possessore e l’entità con la quale sta cercando di interagire.
- Informazioni riguardo la localizzazione del possessore.
Il processo di verifica di validità può sfociare in una violazione di privacy; per tale motivo i verificatori devono considerare la possibilità di respingere credenziali che possano provocare una violazione della privacy.
Credenziali al portatore
Una credenziale al portatore è un’informazione che favorisce la privacy, come un ticket di un concerto, che dà il diritto al possessore di godere di tale risorsa senza rivelare informazioni sensibili del possessore stesso. Sono spesso utilizzate in casi a basso rischio dove la condivisione di credenziali non implica perdite economiche o reputazionali. Esse devono essere create attentamente per far sì che non possano divulgare accidentalmente più informazioni di quelle richieste. L’utilizzo di queste credenziali in più siti differenti crea un elevato rischio di correlazione.
Gli emittenti delle credenziali al portatore devono assicurare che le credenziali portino benefici in tema di privacy, ovvero:
- Monouso, ove possibile
- Non contengono informazioni personali
- Non sono eccessivamente correlabili.
I possessori devono essere avvertiti dal proprio software qualora la propria credenziale contenente informazioni sensibili sia emessa o richiesta, oppure qualora vi sia rischio di correlazione quando il soggetto unisce due credenziali di questa tipologia.
Controlli di validità
Quando processano le credenziali verificabili, i verificatori devono eseguire diversi controlli di validità:
- Lo stato di abilitazione professionale del possessore.
- Data di rinnovo o revoca della licenza.
- Requisiti di un individuo.
- L’esistenza di una relazione tra il possessore e l’entità con la quale sta cercando di interagire.
- Informazioni riguardo la localizzazione del possessore.
Il processo di verifica di validità può sfociare in una violazione di privacy; per tale motivo i verificatori devono considerare la possibilità di respingere credenziali che possano provocare una violazione della privacy.
Condivisione di informazioni con la controparte errata
Quando il possessore decide di condividere le informazioni con il verificatore, può verificarsi che il quest’ultimo agisca in mala fede e richieda informazioni che possono essere utilizzate per danneggiare il possessore.
Gli emittenti dovrebbero cercare di minimizzare il più possibile le informazioni in modo tale da non rendere catastrofico il caso in cui essi condividano le proprie informazioni con la controparte errata. Ad esempio, al posto di condividere il numero di conto bancario per abilitare la visione del saldo, è possibile fornire un token che autorizzi il verificatore a constatare che il saldo superi una determinata somma.
Preferire credenziali monouso
L’utilizzo di credenziali monouso fornisce diversi vantaggi. Il primo è per i verificatori che possono assicurarsi che i dati forniti siano “freschi”. Il secondo è per i possessori, che possono essere sicuri che non essendoci identificatori vecchi, la credenziale non può essere utilizzata per tracciarli o correlarli online. Infine, non vi è la possibilità che i dati vengano rubati, rendendo l’intero sistema sicuro.
Condivisione di informazioni con la controparte errata
Quando il possessore decide di condividere le informazioni con il verificatore, può verificarsi che il quest’ultimo agisca in mala fede e richieda informazioni che possono essere utilizzate per danneggiare il possessore.
Gli emittenti dovrebbero cercare di minimizzare il più possibile le informazioni in modo tale da non rendere catastrofico il caso in cui essi condividano le proprie informazioni con la controparte errata. Ad esempio, al posto di condividere il numero di conto bancario per abilitare la visione del saldo, è possibile fornire un token che autorizzi il verificatore a constatare che il saldo superi una determinata somma.
Preferire credenziali monouso
L’utilizzo di credenziali monouso fornisce diversi vantaggi. Il primo è per i verificatori che possono assicurarsi che i dati forniti siano “freschi”. Il secondo è per i possessori, che possono essere sicuri che non essendoci identificatori vecchi, la credenziale non può essere utilizzata per tracciarli o correlarli online. Infine, non vi è la possibilità che i dati vengano rubati, rendendo l’intero sistema sicuro.
Esempi di utilizzo
Nonostante i numerosi sforzi per assicurare la protezione dei dati, l’utilizzo di credenziali verificabili può condurre alla perdita di privacy. Questo può avvenire quando:
- La stessa credenziale è presentata al medesimo verificatore più di una volta. Il verificatore può dedurre che l’individuo sia lo stesso.
- La stessa credenziale è presentata a diversi verificatori, ma questi verificatori cooperano. Essi possono quindi desumere che la persona che ha presentato la credenziale sia la stessa.
- L’identificatore di un soggetto si riferisce al medesimo soggetto in più presentazioni o a più verificatori. Anche quando vengono presentate varie credenziali, ma l’identificatore è lo stesso, il verificatore può dedurre che il possessore della credenziale sia lo stesso.
- Le informazioni contenute in una credenziale possono essere utilizzate per identificare un individuo. Il verificatore può correlare il possessore con un profilo già esistente utilizzando queste informazioni.
In parte, è possibile mitigare questi rischi:
- Utilizzando un identificatore universale per qualsiasi credenziale di un soggetto e non riutilizzare però la stessa credenziale.
- Costruire API di revoca che non dipendono dall’id della credenziale.
- Evitare l’associazione di informazioni personali con qualsiasi identificatore di lunga data.
Esempi di utilizzo
Nonostante i numerosi sforzi per assicurare la protezione dei dati, l’utilizzo di credenziali verificabili può condurre alla perdita di privacy. Questo può avvenire quando:
- La stessa credenziale è presentata al medesimo verificatore più di una volta. Il verificatore può dedurre che l’individuo sia lo stesso.
- La stessa credenziale è presentata a diversi verificatori, ma questi verificatori cooperano. Essi possono quindi desumere che la persona che ha presentato la credenziale sia la stessa.
- L’identificatore di un soggetto si riferisce al medesimo soggetto in più presentazioni o a più verificatori. Anche quando vengono presentate varie credenziali, ma l’identificatore è lo stesso, il verificatore può dedurre che il possessore della credenziale sia lo stesso.
- Le informazioni contenute in una credenziale possono essere utilizzate per identificare un individuo. Il verificatore può correlare il possessore con un profilo già esistente utilizzando queste informazioni.
In parte, è possibile mitigare questi rischi:
- Utilizzando un identificatore universale per qualsiasi credenziale di un soggetto e non riutilizzare però la stessa credenziale.
- Costruire API di revoca che non dipendono dall’id della credenziale.
- Evitare l’associazione di informazioni personali con qualsiasi identificatore di lunga data.
Considerazioni di sicurezza e privacy
Ci sono svariate considerazioni riguardo la sicurezza che emittenti, possessori e verificatori dovrebbero conoscere quando processano i dati. Ignorare o non capire tali implicazioni può provocare numerose vulnerabilità.
La sicurezza nei protocolli deve rimanere al centro delle prime considerazioni rispetto all’efficienza o meno del sistema stesso: gli attori devo avere gli stessi incentivi e il root of trust deve essere crittograficamente sicuro e publico, garantendo nel contempo privacy.
Altre considerazioni su sicurezza:
Considerazioni di sicurezza e privacy
Ci sono svariate considerazioni riguardo la sicurezza che emittenti, possessori e verificatori dovrebbero conoscere quando processano i dati. Ignorare o non capire tali implicazioni può provocare numerose vulnerabilità.
La sicurezza nei protocolli deve rimanere al centro delle prime considerazioni rispetto all’efficienza o meno del sistema stesso: gli attori devo avere gli stessi incentivi e il root of trust deve essere crittograficamente sicuro e publico, garantendo nel contempo privacy.
Altre considerazioni su sicurezza:
Stanze e librerie della crittografia
Gran parte del modello citato si basa sull’utilizzo della crittografia. Risulta importante per gli attuatori capire il significato delle stanze, delle librerie della crittografia, la loro implementazione e la loro eventuale revisione, per creare e processare le credenziali e le presentazioni in completa sicurezza.
Molte librerie hanno una durata limitata e possono essere soggette ad attacchi oppure a progressi tecnologici. I sistemi di controllo qualità devono assicurare dei meccanismi che siano in grado di aggiornare queste stanze qualora scadute e di invalidare le credenziali contenute sostituendole con delle nuove. Il monitoraggio è importante per assicurare la validità nel corso del tempo di questi sistemi di processazione delle credenziali.
Protezione dell’integrità del contenuto
Le credenziali verificabili contengono spesso un URL per i dati che rimangono al di fuori della credenziale stessa. I contenuti collegati, come le immagini, JSON-LD Contexts, e altri dati, spesso non sono protetti da eventuali manomissioni dato che essi rimangono al di fuori della protezione della prova della credenziale verificabile.
Gli autori di tali documenti, che vogliono assicurare la protezione delle informazioni contenute in questi ultimi, devono utilizzare schemi URL che assicurino l’integrità. Possono essere depositati in cloud decentralizzati, blockchain o cloud sicuri. Due esempi di schemi sono HASHLINK e IPFS.
Stanze e librerie della crittografia
Gran parte del modello citato si basa sull’utilizzo della crittografia. Risulta importante per gli attuatori capire il significato delle stanze, delle librerie della crittografia, la loro implementazione e la loro eventuale revisione, per creare e processare le credenziali e le presentazioni in completa sicurezza.
Molte librerie hanno una durata limitata e possono essere soggette ad attacchi oppure a progressi tecnologici. I sistemi di controllo qualità devono assicurare dei meccanismi che siano in grado di aggiornare queste stanze qualora scadute e di invalidare le credenziali contenute sostituendole con delle nuove. Il monitoraggio è importante per assicurare la validità nel corso del tempo di questi sistemi di processazione delle credenziali.
Protezione dell’integrità del contenuto
Le credenziali verificabili contengono spesso un URL per i dati che rimangono al di fuori della credenziale stessa. I contenuti collegati, come le immagini, JSON-LD Contexts, e altri dati, spesso non sono protetti da eventuali manomissioni dato che essi rimangono al di fuori della protezione della prova della credenziale verificabile.
Gli autori di tali documenti, che vogliono assicurare la protezione delle informazioni contenute in questi ultimi, devono utilizzare schemi URL che assicurino l’integrità. Possono essere depositati in cloud decentralizzati, blockchain o cloud sicuri. Due esempi di schemi sono HASHLINK e IPFS.
Affermazioni non firmate
Questo tipo di credenziali non sono verificabili poichè l’autenticità è ignota o non può comunque essere verificata.
Informazioni dinamiche
Date di scadenza precedenti al termine del periodo di validità espresso dalla credenziale creano un problema per il possessore ed il verificatore. Risulta quindi importante stabilire periodi di validità appropriati al caso di utilizzo ed al ciclo di vita delle informazioni contenute nella credenziale verificabile.
Affermazioni non firmate
Questo tipo di credenziali non sono verificabili poichè l’autenticità è ignota o non può comunque essere verificata.
Informazioni dinamiche
Date di scadenza precedenti al termine del periodo di validità espresso dalla credenziale creano un problema per il possessore ed il verificatore. Risulta quindi importante stabilire periodi di validità appropriati al caso di utilizzo ed al ciclo di vita delle informazioni contenute nella credenziale verificabile.
Furto del dispositivo o impersonificazione
Quando le credenziali sono archiviate in un dispositivo e quest’ultimo viene rubato oppure smarrito, è possibile che qualcuno acceda al sistema utilizzando le credenziali verificabili della vittima. I modi per evitare questo rischio sono:
- Abilitare password, pin, dispositivi di protezione biometrici sul dispositivo.
- Abilitare password, biometria, o autenticazione a più fattori per il wallet.
- Abilitare password, biometria, o autenticazione a più fattori quanto si utilizzano le chiavi crittografiche.
- Utilizzare un dispositivo di firma separato
- Tutte le indicazioni o alcune tra quelle indicate sopra.
Furto del dispositivo o impersonificazione
Quando le credenziali sono archiviate in un dispositivo e quest’ultimo viene rubato oppure smarrito, è possibile che qualcuno acceda al sistema utilizzando le credenziali verificabili della vittima. I modi per evitare questo rischio sono:
- Abilitare password, pin, dispositivi di protezione biometrici sul dispositivo.
- Abilitare password, biometria, o autenticazione a più fattori per il wallet.
- Abilitare password, biometria, o autenticazione a più fattori quanto si utilizzano le chiavi crittografiche.
- Utilizzare un dispositivo di firma separato
- Tutte le indicazioni o alcune tra quelle indicate sopra.
Il mercato europeo e comunitario ed il regolamento sull’identità digitale
Il Regolamento eIDAS (electronic IDentification Authentication and Signature) – Regolamento UE n° 910/2014 sull’identità digitale – ha l’obiettivo di fornire una base normativa su identità digitale a livello comunitario per i servizi fiduciari e i mezzi di identificazione elettronica degli stati membri. Grazie al progetto FICEP, “server transfrontaliero italiano”, con la realizzazione di un nodo eIDAS nazionale è possibile per i cittadini italiani accedere ai servizi online di altri paesi comunitari utilizzando le credenziali ottenute nel sistema pubblico di identità digitale SPID, come anche con la Carta d’Identità Elettronica (CIE).
La Commissione europea sta attualmente valutando questo quadro normativo e ha condotto una consultazione aperta dal 24 luglio al 2 ottobre 2020. L’obiettivo della consultazione era raccogliere feedback sui fattori trainanti e sugli ostacoli allo sviluppo e alla diffusione dei servizi fiduciari e dell’eID in Europa. Lo studio ha anche preso in considerazione l’impatto delle opzioni per la realizzazione di un’identità digitale dell’UE.
Il mercato europeo e comunitario ed il regolamento sull’identità digitale
Il Regolamento eIDAS (electronic IDentification Authentication and Signature) – Regolamento UE n° 910/2014 sull’identità digitale – ha l’obiettivo di fornire una base normativa su identità digitale a livello comunitario per i servizi fiduciari e i mezzi di identificazione elettronica degli stati membri. Grazie al progetto FICEP, “server transfrontaliero italiano”, con la realizzazione di un nodo eIDAS nazionale è possibile per i cittadini italiani accedere ai servizi online di altri paesi comunitari utilizzando le credenziali ottenute nel sistema pubblico di identità digitale SPID, come anche con la Carta d’Identità Elettronica (CIE).
La Commissione europea sta attualmente valutando questo quadro normativo e ha condotto una consultazione aperta dal 24 luglio al 2 ottobre 2020. L’obiettivo della consultazione era raccogliere feedback sui fattori trainanti e sugli ostacoli allo sviluppo e alla diffusione dei servizi fiduciari e dell’eID in Europa. Lo studio ha anche preso in considerazione l’impatto delle opzioni per la realizzazione di un’identità digitale dell’UE.
Eidas Bridge e il ruolo del Trust Service Provider
La nuova proposta per una regolamentazione dell’identità digitale è destinata ad individuare i limiti presenti in eIDAS, migliorando l’efficacia del framework ed estendendo i benefici al settore privato.
L’eIDAS SSI bridge assiste l’emittente nel processo di firma di una credenziale verificabile, e il verificatore, nel processo di verificazione, aiutandolo ad identificare l’emittente (persona legale) dietro al suo DID.
“Attraversando” l’eIDAS Bridge, la credenziale verificabile è provata in modo sicuro.
L’European Self-Sovereign Identity (SSI) framework (ESSIF), definendo le specificazioni necessarie, permetterà ai cittadini di creare, controllare e utilizzare la propria identità digitale. ESSIF mira ad essere conforme al GDPR e alle linee definite da eIDAS per assicurare i benefici derivanti dall’esistenza di questo nuovo framework. ESSIF fa parte della European blockchain service infrastructure (EBSI). EBSI è un’iniziativa congiunta della Commissione Europea e della European Blockchain Partnership (EBP) nata per fornire servizi pubblici ai cittadini europei utilizzando la tecnologia blockchain.
I Trust Service Provider sono le realtà che hanno il compito di garantire prima di tutto la certezza e l’integrità di identificazione per la firma elettronica, per l’autenticazione e per la gestione dei certificati digitali. eIDAS richiede che l’Unione Europea realizzi uno speciale elenco fiduciario per tutti i fornitori di servizi TSP “qualificati”. All’interno del contesto SSI, i Trusted Service Provider hanno un nuovo ruolo e funzione, ovvero quella dei Trusted Issuer.
Eidas Bridge e il ruolo del Trust Service Provider
La nuova proposta per una regolamentazione dell’identità digitale è destinata ad individuare i limiti presenti in eIDAS, migliorando l’efficacia del framework ed estendendo i benefici al settore privato.
L’eIDAS SSI bridge assiste l’emittente nel processo di firma di una credenziale verificabile, e il verificatore, nel processo di verificazione, aiutandolo ad identificare l’emittente (persona legale) dietro al suo DID.
“Attraversando” l’eIDAS Bridge, la credenziale verificabile è provata in modo sicuro.
L’European Self-Sovereign Identity (SSI) framework (ESSIF), definendo le specificazioni necessarie, permetterà ai cittadini di creare, controllare e utilizzare la propria identità digitale. ESSIF mira ad essere conforme al GDPR e alle linee definite da eIDAS per assicurare i benefici derivanti dall’esistenza di questo nuovo framework. ESSIF fa parte della European blockchain service infrastructure (EBSI). EBSI è un’iniziativa congiunta della Commissione Europea e della European Blockchain Partnership (EBP) nata per fornire servizi pubblici ai cittadini europei utilizzando la tecnologia blockchain.
I Trust Service Provider sono le realtà che hanno il compito di garantire prima di tutto la certezza e l’integrità di identificazione per la firma elettronica, per l’autenticazione e per la gestione dei certificati digitali. eIDAS richiede che l’Unione Europea realizzi uno speciale elenco fiduciario per tutti i fornitori di servizi TSP “qualificati”. All’interno del contesto SSI, i Trusted Service Provider hanno un nuovo ruolo e funzione, ovvero quella dei Trusted Issuer.
SSI con GPPR: Selective Disclosure e data minimization
Un ulteriore elemento che valorizza l’Auto-Sovereign Identity come nuovo modello di identità digitale è il suo rapporto con il GDPR.
Il regolamento generale sulla protezione dei dati in sigla RGPD (o GDPR in inglese General Data Protection Regulation), ufficialmente regolamento (UE) n. 2016/679, è un regolamento dell’Unione Europea in materia di trattamento dei dati personali e privacy, adottato il 27 aprile 2016, pubblicato nella Gazzetta Ufficiale dell’Unione Europea il 4 maggio 2016 ed entrato in vigore il 24 maggio dello stesso anno ed operativo dal 25 maggio 2018.
Nei 10 principi su cui si basa questo nuovo framework, il numero 9 è il concetto di “minimizzazione dei dati”, che consente quella che viene definita “divulgazione selettiva”: mostrare solo le informazioni richieste dalla SP.
All’interno del GDPR, ritroviamo questo principio in diversi articoli come:
- Art. 5 “Principles relating to processing of personal data”,
- Art. 47 “Binding corporate rules”,
- Art. 25 “Data protection by design and by default”,
- Art. 89 “Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes”.
SSI con GPPR: Selective Disclosure e Data Minimization
Un ulteriore elemento che valorizza l’Auto-Sovereign Identity come nuovo modello di identità digitale è il suo rapporto con il GDPR.
Il regolamento generale sulla protezione dei dati in sigla RGPD (o GDPR in inglese General Data Protection Regulation), ufficialmente regolamento (UE) n. 2016/679, è un regolamento dell’Unione Europea in materia di trattamento dei dati personali e privacy, adottato il 27 aprile 2016, pubblicato nella Gazzetta Ufficiale dell’Unione Europea il 4 maggio 2016 ed entrato in vigore il 24 maggio dello stesso anno ed operativo dal 25 maggio 2018.
Nei 10 principi su cui si basa questo nuovo framework, il numero 9 è il concetto di “minimizzazione dei dati”, che consente quella che viene definita “divulgazione selettiva”: mostrare solo le informazioni richieste dalla SP.
All’interno del GDPR, ritroviamo questo principio in diversi articoli come:
- Art. 5 “Principles relating to processing of personal data”,
- Art. 47 “Binding corporate rules”,
- Art. 25 “Data protection by design and by default”,
- Art. 89 “Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes”.
Case Studies: Cittadinanza per discendenza
Sam vuole affermare la sua cittadinanza Statunitense dato che sua mamma è Americana. Sam possiede un certificato digitale del Kenya, Paese in cui è nato mentre sua madre era soldato dell’ONU. Egli possiede inoltre una versione digitale del passaporto Statunitense di sua mamma. Siccome il cognome di sua mamma è cambiato in seguito al matrimonio, Sam presenta inoltre il documento di matrimonio con il cognome da nubile e quello da sposata. Sam sta facendo richiesta presso la Segreteria di Stato.
Scenario:
La mamma di Sam ha inoltrato al figlio il certificato, i documenti, il passaporto come credenziali verificabili.Egli crea una presentazione digitale che include queste credenziali e che affermi la relazione di parentela. In seguito egli visita il sito della Segreteria di Stato , crea un account, inizia la procedura e carica la sua presentazione verificabile come prova. Alla fine del processo Sam ottiene il passaporto tradizionale ed una versione digitale.
Credenziali Verificabili:
- certificato di nascita: stabilisce il rapporto con la madre con il cognome da nubile
- documento di matrimonio: accerta il cambiamento del cognome della madre
- passaporto della madre: afferma la cittadinanza della madre
- passaporto di Sam: afferma che Sam è il bambino del certificato di nascita
Presentazione Verificabile:
Una presentazione verificabile deve includere queste credenziali, aggiunge il nome, foto, data di nascita insieme ad altre affermazioni:
- Sam è il bambino indicato dal certificato.
- Se la donna presente nel certificato di nascita, nel passaporto, nel documento di matrimonio sono la stessa donna e contemporaneamente la madre.
- Sam è legalmente responsabile delle proprie affermazioni per i diritti di cittadinanza.
- Sam ha legamente il diritto di ricevere la cittadinza.
Il dipartimento di Stato verificherà cosi le credenziali fornite da Sam, correlando i dati con quelli già in possesso.
Minacce e soluzioni durante il processo di identificazione
Minacce: Terrorismo/furto d’identità.
Una persona in malafede può fingersi Sam per ottenere il passaporto. Ovviamente, egli deve essere in grado di raccogliere tutti i documenti richiesti per completare il processo di ottenimento del passaporto.
Soluzione: constatazione dell’identità basata sulla presentazione ed altri dati che vanno ben oltre quanto contenuto nella presentazione stessa e le informazioni fornite precedentemente.
Soluzione: conferma dell’identità basata sul contenuto delle affermazioni fornite, potenzialmente con dati integrati; come dati non attualmente contenuti nel passaporto, certificati di nascita, documenti di matrimonio. Ad esempio, un modello biometrico potrebbe essere incluso nel certificato di nascita e quindi usato concretamente per affermare la propria identità nel momento in cui si invia la presentazione.
Minaccia: Esposizione di informazioni private.
Nella conservazione di informazioni potenzialmente manomettibili e inviandole al di fuori del proprio network, si va incontro ad un potenziale attacco da parte di cybercriminali.
Soluzione: Criptare i dati
Soluzione: Criptare le affermazioni per ogni verificatore.
Soluzione: Inviare le affermazioni in copia nascosta ad ogni verificatore.
Soluzione: Criptare la presentazione per ogni verificatore. In questo modo nessun emittente verrà coinvolto.
Case Studies: Cittadinanza per discendenza
Sam vuole affermare la sua cittadinanza Statunitense dato che sua mamma è Americana. Sam possiede un certificato digitale del Kenya, Paese in cui è nato mentre sua madre era soldato dell’ONU. Egli possiede inoltre una versione digitale del passaporto Statunitense di sua mamma. Siccome il cognome di sua mamma è cambiato in seguito al matrimonio, Sam presenta inoltre il documento di matrimonio con il cognome da nubile e quello da sposata. Sam sta facendo richiesta presso la Segreteria di Stato.
Scenario:
La mamma di Sam ha inoltrato al figlio il certificato, i documenti, il passaporto come credenziali verificabili.Egli crea una presentazione digitale che include queste credenziali e che affermi la relazione di parentela. In seguito egli visita il sito della Segreteria di Stato , crea un account, inizia la procedura e carica la sua presentazione verificabile come prova. Alla fine del processo Sam ottiene il passaporto tradizionale ed una versione digitale.
Credenziali Verificabili:
- certificato di nascita: stabilisce il rapporto con la madre con il cognome da nubile
- documento di matrimonio: accerta il cambiamento del cognome della madre
- passaporto della madre: afferma la cittadinanza della madre
- passaporto di Sam: afferma che Sam è il bambino del certificato di nascita
Presentazione Verificabile:
Una presentazione verificabile deve includere queste credenziali, aggiunge il nome, foto, data di nascita insieme ad altre affermazioni:
- Sam è il bambino indicato dal certificato.
- Se la donna presente nel certificato di nascita, nel passaporto, nel documento di matrimonio sono la stessa donna e contemporaneamente la madre.
- Sam è legalmente responsabile delle proprie affermazioni per i diritti di cittadinanza.
- Sam ha legamente il diritto di ricevere la cittadinza.
Il dipartimento di Stato verificherà cosi le credenziali fornite da Sam, correlando i dati con quelli già in possesso.
Minacce e soluzioni durante il processo di identificazione
Minacce: Terrorismo/furto d’identità.
Una persona in malafede può fingersi Sam per ottenere il passaporto. Ovviamente, egli deve essere in grado di raccogliere tutti i documenti richiesti per completare il processo di ottenimento del passaporto.
Soluzione: constatazione dell’identità basata sulla presentazione ed altri dati che vanno ben oltre quanto contenuto nella presentazione stessa e le informazioni fornite precedentemente.
Soluzione: conferma dell’identità basata sul contenuto delle affermazioni fornite, potenzialmente con dati integrati; come dati non attualmente contenuti nel passaporto, certificati di nascita, documenti di matrimonio. Ad esempio, un modello biometrico potrebbe essere incluso nel certificato di nascita e quindi usato concretamente per affermare la propria identità nel momento in cui si invia la presentazione.
Minaccia: Esposizione di informazioni private.
Nella conservazione di informazioni potenzialmente manomettibili e inviandole al di fuori del proprio network, si va incontro ad un potenziale attacco da parte di cybercriminali.
Soluzione: Criptare i dati
Soluzione: Criptare le affermazioni per ogni verificatore.
Soluzione: Inviare le affermazioni in copia nascosta ad ogni verificatore.
Soluzione: Criptare la presentazione per ogni verificatore. In questo modo nessun emittente verrà coinvolto.