Vai al contenuto
Financial Context Wiki

Identità decentralizzata (DID)

Guida pratica a identificatori decentralizzati e credenziali verificabili: cosa provano, come funzionano emissione e presentazione e quali rischi di fiducia, privacy e recupero restano.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

L’identità decentralizzata è un’architettura in cui un soggetto usa identificatori e credenziali protette crittograficamente tra servizi senza rendere un account di piattaforma la fonte universale dell’identità. Gli elementi comuni sono identificatori decentralizzati (DID), credenziali verificabili (VC), software del titolare come un wallet e regole su quali emittenti, prove e livelli di garanzia accettare.

Un DID è un URI come did:example:123. Il metodo DID definisce creazione, risoluzione, aggiornamento e disattivazione. La risoluzione può restituire un documento DID con metodi di verifica, relazioni come authentication o assertionMethod ed endpoint facoltativi. Controllare la chiave corrispondente prova il controllo del DID secondo quel metodo; da solo non prova nome legale, età, unicità, impiego o proprietà di un account esterno.

Una credenziale verificabile contiene affermazioni di un emittente su uno o più soggetti. Il titolare la conserva e può creare una presentazione verificabile per un verificatore. Una verifica crittografica riuscita stabilisce integrità e paternità dei dati protetti secondo il meccanismo scelto. Il verificatore deve ancora decidere se fidarsi dell’emittente, se le affermazioni soddisfano la politica, se la credenziale è attuale e se il presentatore può usarla.

“Decentralizzata” non significa quindi priva di fiducia, anonima, basata su blockchain o senza intermediari. Identificatori, credenziali, registri, wallet e politiche possono essere separati affinché un solo fornitore di accesso non osservi e controlli ogni relazione. La decentralizzazione reale dipende da emittenti, operatori dei metodi DID, servizi di stato, fornitori di wallet, amministratori del recupero, chiavi di governance e politiche dei verificatori.

Come funziona

  1. Definire affermazione e quadro di fiducia. Precisare soggetto, attributi richiesti, emittenti ammessi, processo di verifica, livello di garanzia, conservazione, giurisdizione e ricorso. Un formato crittografico non decide se università, governo, datore o comunità sia l’autorità adatta.
  2. Creare o ottenere identificatori e chiavi. Emittente e titolare possono usare DID, URL HTTPS o altri identificatori supportati. Se usano un DID, il metodo determina registro e ciclo di vita. Il controllore protegge la chiave privata; il documento risolto espone solo materiale ed endpoint necessari.
  3. Verificare e vincolare il soggetto. L’emittente controlla le prove secondo politica e lega le affermazioni al soggetto della credenziale. Il vincolo può riferirsi a chiave del titolare, account o altro identificatore. Va distinta la prova su una persona da quella che l’attuale presentatore controlli una chiave.
  4. Emettere la credenziale. L’emittente crea affermazioni, date di validità, schema o tipo e riferimento di stato, poi protegge la credenziale con una prova supportata. In Data Integrity, cryptosuite, verificationMethod, proofPurpose e proofValue indicano come verificare.
  5. Conservare e selezionare. Il titolare tiene la credenziale in un wallet locale o ospitato. Il wallet dovrebbe spiegare la richiesta, divulgare solo i dati necessari se il formato lo consente ed evitare il riuso silenzioso di un identificatore stabile in contesti non correlati.
  6. Presentare con attualità e vincolo al destinatario. Il verificatore invia identità, scopo, nonce o sfida e scadenza. Il titolare restituisce credenziale o presentazione derivata legata alla richiesta. Controlli di dominio e sfida impediscono il replay verso altro verificatore o sessione.
  7. Verificare crittografia e politica. Risolvere il materiale dell’emittente da fonte autenticata; validare suite, scopo, sfida, dominio, date, schema e stato; applicare poi le regole aziendali. verified: true è un input all’autorizzazione, non un ordine di accesso.
  8. Gestire il ciclo di vita. Ruotare chiavi compromesse, sospendere o revocare, aggiornare lo stato, offrire recupero e ricorsi, conservare prove di audit e pubblicare piani di migrazione o chiusura. La verifica storica richiede regole per vecchie chiavi, documenti e momenti di presentazione.

I tre ruoli sono emittente, titolare e verificatore; il soggetto può differire dal titolare. Un genitore può custodire una credenziale sul figlio, un agente aziendale presentarne una sull’organizzazione. Senza un vincolo stabilito da credenziale e protocollo, l’implementazione non deve presumere che il presentatore sia il soggetto.

DID e VC sono indipendenti. Una VC può usare un identificatore dell’emittente non DID e un DID esistere senza VC. Un metodo DID può usare blockchain, database distribuito, dominio web o scambio peer-to-peer. Sicurezza e governance vanno valutate direttamente, non dedotte dal prefisso did:.

Esempio pratico

Un servizio deve confermare che il cliente abbia almeno 18 anni senza raccogliere la data di nascita. Un’autorità accettata verifica il cliente ed emette al wallet una credenziale di età. Può contenere la data o solo l’affermazione ageOver18; le due scelte hanno proprietà diverse di divulgazione e riuso.

Alla registrazione il servizio richiede per merchant.example una presentazione sopra i 18 anni, sfida n-7f3a e finestra di 5 minuti. Il wallet mostra la richiesta e, se credenziale e suite lo consentono, deriva una presentazione che rivela solo il predicato necessario. Il servizio controlla metodo, prova, sfida, dominio, finestra e stato prima di registrare il risultato minimo per l’audit.

Il flusso riduce la conservazione di immagini o date complete, ma non elimina fiducia e rischio. L’autorità può iscrivere la persona errata; wallet o dispositivo possono essere compromessi; identificatore stabile o richiesta di stato possono correlare usi; il servizio può chiedere troppi dati; una sospensione errata può negare accesso. La divulgazione selettiva limita i dati presentati, non tutti i metadati visibili a emittenti, wallet, reti e verificatori.

La rotazione delle chiavi mostra un altro limite. Se l’emittente sostituisce una chiave compromessa, le nuove credenziali devono usare il nuovo metodo. La verificabilità di una vecchia dipende dalla cronologia DID, dall’ora della prova, dalla politica e dallo stato. Eliminare la vecchia chiave dal documento corrente può rompere controlli storici legittimi o nascondere quale chiave fosse autorizzata alla creazione.

Rischi e controlli

  • Affermazioni false o troppo ampie: Una firma valida conserva quanto detto dall’emittente, non lo rende corretto. Definire prove, responsabilità, garanzia, audit, scadenza e correzione.
  • Vincolo debole del titolare: Una credenziale copiata può essere usata da altri se la presentazione non prova il controllo della chiave prevista. Legare prova di possesso a verificatore, sfida, scopo e sessione quando opportuno.
  • Compromissione di chiavi e wallet: Malware, phishing, takeover cloud o backup insicuri espongono credenziali e chiavi. Usare autenticazione resistente al phishing, protezione hardware se giustificata, segnalazione e recupero ristretto.
  • Centralizzazione del recupero: Un solo amministratore può diventare il vero controllore. Documentare chi sostituisce chiavi, quali prove servono, come rilevare abuso e come ricorrere o migrare.
  • Correlazione: Riutilizzare DID, metodo, firma, endpoint o percorso di stato può collegare attività. Usare identificatori per coppia, chiavi o prove separate per dominio, stato privato e test dei metadati.
  • Dati personali pubblici: Documenti DID e cronologia possono essere indicizzati e difficili da cancellare. Tenere nomi, numeri, biometria e affermazioni personali fuori da documenti pubblici e registri immutabili.
  • Privacy e disponibilità dello stato: Contattare sempre l’emittente rivela l’uso; un guasto blocca utenti validi. Preferire stato privato e memorizzabile, con limiti di attualità, aggiornamenti autenticati e comportamento d’errore definito.
  • Abuso della revoca: Emittente o amministratore può censurare sospendendo o cambiando stato. Limitare autorità, registrare modifiche, mostrare motivo e ricorso e supportare sostituzione o altri emittenti.
  • Rischio di risoluzione e metodo: Un resolver può restituire documenti vecchi o dannosi; un metodo dipendere da infrastruttura centrale. Autenticare risultati e valutare finalità, autorizzazione, disponibilità, governance e versioni.
  • Disallineamento semantico: Due sistemi possono leggere gli stessi campi e interpretare diversamente affermazione, unità, giurisdizione o garanzia. Usare schemi e vocabolari stabili, validare contesto e tipo, versionare la politica.
  • Replay e confusione del verificatore: Una presentazione non legata a nonce, destinatario, dominio, azione e scadenza può essere riusata o reindirizzata. Validare ogni vincolo del protocollo.
  • Divulgazione eccessiva: Anche con selettività, il verificatore può chiedere l’intera credenziale. Imporre minimizzazione in politica e interfaccia, registrare lo scopo e non rendere obbligatori i campi facoltativi per abitudine.
  • Blocco dell’ecosistema: Wallet, prove, registri o recuperi proprietari riducono portabilità. Testare conformità, esportazione, più wallet, agilità crittografica e migrazione.
  • Cattura della governance: Multisig o registro non garantiscono controllo ampio se un fornitore sceglie emittenti, aggiornamenti, schemi e stato. Mappare autorità per componente e pubblicare i controlli di modifica.

Idee sbagliate comuni

  • “Un DID prova chi è una persona.” Identifica un soggetto e può esporre metodi; gli attributi richiedono altre affermazioni, prove e decisioni di fiducia.
  • “Una credenziale valida rende vera l’affermazione.” La verifica mostra la prova attesa e dati integri, non convalida l’indagine o il giudizio originario.
  • “Il titolare è sempre il soggetto.” I ruoli possono differire; quando serve, il verificatore necessita di un vincolo esplicito tra soggetto e presentatore.
  • “Tutto deve stare on-chain.” Lo spazio pubblico immutabile amplifica privacy, correlazione, cancellazione e governance. Molti sistemi tengono le credenziali off-chain.
  • “La divulgazione selettiva garantisce anonimato.” Attributi, identificatori, impronte delle prove, query, tempi, IP e registri possono ancora correlare.
  • “Decentralizzato significa senza emittente o amministratore fidato.” La fiducia è distribuita ed esplicita, non rimossa. Emissione, verifica, wallet, recupero, stato e accettazione restano governati.
  • “Un DID equivale a una persona.” Una persona controlla molti DID; un DID può identificare organizzazione, dispositivo, dati, ruolo o altro soggetto. Unicità e umanità richiedono altri meccanismi.
  • “La firma del wallet basta ad autenticare.” Prova il controllo della chiave in condizioni definite. Servono ancora resistenza al phishing, attualità, destinatario, autorizzazione e recupero.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...