Chapter 3

Obiettivi Formativi:

  • Come è costruita una credenziale verificabile e i suoi principali elementi
  • Come una credenziale verificabile può garantire standard sicuri e scalabili
  • Come una credenziale verificabile soddisfa livelli di privacy e sicurezza
  • Qual è lo stato dell’arte dalla SSI nel confine normativo europeo

Concetti base delle credenziali verificabili

Quando due software scambiano dei dati, è necessario che essi utilizzino una terminologia che entrambi capiscano. A ciò si riferisce il contesto della conversazione.

Le credenziali verificabili e le presentazioni hanno diversi attributi e valori che sono identificati dagli URI. Questa specificazione usa la proprietà @context per mappare gli URI richiesti da specifiche credenziali e presentazioni.

Le credenziali verificabili e le presentazioni hanno diversi attributi e valori che sono identificati dagli URI.

Questa specificazione usa la proprietà @context per mappare 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

Esprimendo affermazioni riguardo un argomento specifico argomento, è spesso utile utilizzare delle tipologie di identificatori in modo che anche altre entità possano esprimersi riguardo il medesimo argomento.

Tale specificazione definisce la proprietà id. Quest’ultima ha lo scopo di riferirsi inequivocabilmente ad un oggetto, una persona, un prodotto, un’organizzazione. Utilizzando questa proprietà si permette l’espressione di affermazioni riguardo uno specifico argomento della credenziale verificabile.

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:

  1. il primo è per la credenziale verificabile ed utilizza un URL http.
  2. Il secondo identificatore è per il soggetto della credenziale e utilizza un identificatore decentralizzato, il DID.

 

TYPES

I software che 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

Esprimendo affermazioni riguardo un argomento specifico argomento, è spesso utile utilizzare delle tipologie di identificatori in modo che anche altre entità possano esprimersi riguardo il medesimo argomento.

Tale specificazione definisce la proprietà id. Quest’ultima ha lo scopo di riferirsi inequivocabilmente ad un oggetto, una persona, un prodotto, un’organizzazione. Utilizzando questa proprietà si permette l’espressione di affermazioni riguardo uno specifico argomento della credenziale verificabile.

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:

  1. il primo è per la credenziale verificabile ed utilizza un URL http.
  2. Il secondo identificatore è per il soggetto della credenziale e utilizza un identificatore decentralizzato, il DID.

 

EMITTENTE

La credenziale verificabile DEVE avere la proprietà “emittente”.

Il valore della proprietà “emittente” DEVE essere o 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 possono essere utilizzate per verificare la credenziale.

Rimane possibile esprimere informazioni aggiuntive riguardo l’emittente associando un oggetto alla proprietà “emittente”

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 più vicino 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 validazione, e i dettagli necessari a valutare tale prova, DEVONO essere espressi per una credenziale o una presentazione per renderla verificabile. 

Si identificano due meccanismi differenti: uno esterno ed uno integrato. Il meccanismo esterno rappresenta l’espressione di questo modello di dati, come il JSON Web token. Nel meccanismo integrato invece la prova è inclusa nei dati come ad esempio una Linked Data Signature.

Una o più prove crittografiche possono essere utilizzate per rilevare manomissioni e verificare l’autorevolezza di una credenziale. Il metodo specifico utilizzato DEVE essere specificato utilizzando la proprietà “type”.

Se una firma digitale è utilizzata per il meccanismo di validazione, la proprietà “proof” deve contenere il nome del soggetto firmatario, una sua referenza 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.

PRESENTAZIONE

Le presentazioni possono essere 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 rappresetna l’uso più comune delle presentazioni. 

La presentazione verificabile è solitamente composta dalle seguenti proprietà:

  1. id: la proprietà id è facoltativa e può essere utilizzata per fornire un identificatore unico per la presentazione.
  2. type: la proprietà “type” è richiesta ed esprime il tipo di presentazione, ad esempio VerifiablePresentation
  3. 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. 
  4. possessore: se presente, il valore associato è un URI riferito all’entità che ha generato la presentazione.
  5. prova: se presente, il valore di questa proprietà assicura la verificabilità della presentazione.

     

    Concetti avanzati delle credenziali verificabili

    La più comune sequenza di azioni fatta dagli attori nel processo di autorizzazione e/o identificazione è concepita come di seguito:

    1. L’emittente emette la credenziale al possessore.
    2. Il possessore porge la credenziale al verificatore
    3. Il verificatore 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”, ovvero 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.

    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.

    Utilizzo della proprietà “credentialSchema” per permettere la validazione dello schema JSON:

    Nell’esempio sopra, l’emittente sta specificando un credentialSchema, che indica un file [JSON-SCHEMA-2018] che può essere utilizzato dal verificatore per determinare se la credenziale verificabile è ben costruita. 

    Utilizzo della proprietà “credentialSchema” per permettere la validazione zero-knowledge. Nell’esempio in basso, 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. 
    • Scelta accurata 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; la 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 che contengono informazioni presenti nella credenziale originale zero-knowledge. 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.

      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
      • Monouso
      • Non utilizzati del tutto, oppure sostituiti da token nuovi e 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 credenziali 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.

      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 tokenizzare 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.

            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 le implicazioni può provocare numerose vulnerabilità.

            La sicurezza nei protocolli deve rimanere al centro delle prime considerazioni della efficienza o meno dello stesso sistema: 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

             Alcuni aspetti del modello descritto possono essere protetti attraverso l’utilizzo della crittografia. Risulta importante per gli attuatori capire il significato delle stanze e delle librerie della crittografia utilizzate per creare e processare le credenziali e le presentazioni. Implementare e revisionare sistemi crittografici richiede un elevato livello di esperienza.  

            Queste 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à. 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.

            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:

             

            1. Abilitare password, pin, dispositivi di protezione biometrici sul dispositivo.
            2. Abilitare password, biometria, o autenticazione a più fattori per il wallet.
            3. Abilitare password, biometria, o autenticazione a più fattori quanto si utilizzano le chiavi crittografiche.
            4. Utilizzare un dispositivo di firma separato
            5. 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.

             

            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 e GPPR: Selective Disclosure e data minimization

              Un ulteriore elemento che valorizza la Self-Sovereign Identity come nuovo modello di identità digitale è il suo rapporto con il GDPR. Nei 10 principi su cui si fonda questo nuovo framework, il numero 9 è il concetto “data minimization”, il quale permette quello che viene definita “divulgazione selettiva”: mostrare esclusivamente le informazioni richieste dal 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

                Il

                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.
                • La madre presente nel certificato di nascita, la persona nel passaporto, la sposa nel documento di matrimonio sono la stessa donna.

                Sam è legalmente responsabile delle proprie affermazioni per i diritti di cittadinanza. Sam is legally liable for his claim to the rights of citizenship. Il dipartimento di Stato verifica le credenziali fornite da Sam, correlando i dati con quelli già in possesso.

                MINACCE:

                • 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. 
                  • Risposta: constatazione dell’identità basata sulla presentazione ed altri dati che vanno ben oltre quanto contenuto nella presentazione stessa e le informazioni fornite precedentemente.
                  • Risposta: 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 può quindi essere 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.
                  • Risposta: Criptare i dati 
                  • Response: Criptare le affermazioni per ogni verificatore. 
                  • Response: Inviare le affermazioni in copia nascosta ad ogni verificatore.

                Response: Criptare la presentazione per ogni verificatore. In questo modo nessun emittente verrà coinvolto.