Il modulo è stato inviato con successo.
Ulteriori informazioni sono contenute nella vostra casella di posta elettronica.
AssumeteciSelezionare la lingua
Chi siamo
ServiziTecnologiePortafoglio
Probabilmente l'avete visto anche voi: date a GPT un selfie, chiedete un documento in stile passaporto e in pochi minuti otterrete qualcosa che può superare i controlli visivi di base. Se si aggiungono la clonazione vocale e i video sintetici, la “vivacità” inizia a sembrare un teatro. È questa la vera svolta dell'identità digitale in 2026. Lo stesso modello KYC basato sulle foto è in via di esaurimento. Se la prova dell'identità dipende ancora dal fatto che le immagini sono difficili da falsificare, si sta costruendo sulla sabbia.
Dove ci porta tutto questo? Con un cambiamento piuttosto ovvio: abbandonare l'archiviazione dei dati di identità e passare alla verifica crittografica delle richieste. Invece di raccogliere la scansione di un passaporto e parcheggiarla in un altro database, il sistema chiede una prova: sei maggiorenne, hai superato il KYC, sei autorizzato a questa transazione, e può dimostrarlo senza rivelare nient'altro?
Ma cosa cambia esattamente? Perché improvvisamente si parla di DID e di credenziali verificabili?
Perché in un modello basato sul DID, la fiducia non deriva dall'aspetto di qualcosa. Viene da chi l'ha firmata e se si può dimostrare il controllo su di essa. Un selfie deepfake non è utile se il verificatore si aspetta una credenziale firmata da un emittente affidabile e legata alle vostre chiavi crittografiche. Non si sta più cercando di “sembrare veri”. Si sta dimostrando il possesso di una richiesta valida e firmata. Le immagini smettono di essere la fonte di fiducia. Subentrano le firme.
E questo è lo scopo di questa guida: Mostrerò come funziona questo modello, perché sta diventando la strada da seguire e dove si inserisce la blockchain.
Un identificatore decentralizzato, o DID, è un identificatore basato su URI progettato per essere controllato attraverso chiavi crittografiche piuttosto che emesso e gestito da una directory centrale. Nell'ambito del Consorzio Mondiale del Web (W3C) Secondo lo standard DID, un DID si risolve in un documento DID che informa altri sistemi su come verificare le firme, autenticare il controllore o scoprire gli endpoint di servizio associati a quell'identificatore. In parole povere: un DID non è il vostro profilo, il vostro passaporto o il vostro account. È il puntatore che le altre parti utilizzano per verificare il controllo di uno specifico identificatore e delle chiavi che lo sottendono.
È qui che le persone spesso appiattiscono tutto in “un altro ID”. Non è così.
Un indirizzo e-mail è un identificatore all'interno del sistema di qualcun altro. Se il provider sospende l'account, l'identificatore è di fatto scomparso. Un SSN è un identificatore rilasciato dallo Stato, ma non ha un livello di prova crittografica incorporato; chiunque ottenga il numero può riprodurlo. I token OAuth sono di nuovo diversi: non sono affatto identificatori di identità, ma artefatti di accesso delegato rilasciati da un server di autorizzazione in modo che un client possa chiamare una risorsa protetta. Utile, sì. Strato di identità portatile, no.
Un DID funziona in modo diverso. Si tratta di un problema che deve essere risolto, non semplicemente cercato in un database di fornitori. Il controllo spetta al soggetto attraverso il materiale chiave e le regole del metodo DID, non a un provider di posta elettronica, a una piattaforma SaaS o a un broker di identità. Questa distinzione è importante nella pratica. Se state costruendo credenziali riutilizzabili, login basati su portafogli o flussi di verifica che devono funzionare al di là dei confini dell'organizzazione, un'e-mail o un ID utente specifico per un'applicazione non porteranno una semantica di fiducia sufficiente. Un DID invece sì.
A livello di sintassi, il modello W3C è semplice: un DID ha tre parti: lo schema DID, il nome del metodo e l'identificatore specifico del metodo. In altre parole: did:metodo:identificatore.
Prendere did:web:example.com come esempio concreto.
Con did:web, La risoluzione di solito corrisponde a un documento DID pubblicato in una posizione HTTPS ben nota su quel dominio. Con qualcosa come did:ethr, La risoluzione dipende dalle regole dei metodi legati a Ethereum. Stessa sintassi DID, diverso modello di fiducia e aggiornamento.
Questo è il punto chiave: la stringa DID stessa è solo l'handle. Il metodo indica come risolverla. Il documento DID fornisce il materiale di verifica. Una volta ottenuto, è possibile verificare le firme, autenticare un titolare o convalidare la presentazione di una credenziale. senza trattare l'identificatore come un'altra riga nella tabella utenti di qualcuno..
Finora abbiamo considerato le DID e le credenziali verificabili come strutture di dati: identificatori, documenti, firme. Ma questa è solo una parte di un sistema di identità funzionante. Nelle implementazioni reali, il problema più difficile è l'interazione: come vengono emesse le credenziali, come vengono presentate e come i verificatori decidono se fidarsi di esse.
Nei sistemi di produzione come il Portafoglio d'identità digitale dell'UE o Patente mobile statunitense (mDL) I piloti, i portafogli e i verificatori non si limitano a “risolvere una DID” e si fermano lì. Comunicano attraverso protocolli e formati di credenziali definiti:
La distinzione importante è che le DID e le credenziali verificabili definiscono cosa è in corso di verifica. Questi protocolli definiscono come si muove tra l'emittente, il titolare e il verificatore nei sistemi reali.
Senza questo livello, i DID rimangono un meccanismo di risoluzione. Con esso, diventano parte di un'infrastruttura di identità funzionante.
L'identità decentralizzata è un modello in cui gli identificatori, le credenziali e i flussi di verifica non sono controllati da un singolo fornitore. Al contrario, l'identità è ancorata alle chiavi crittografiche (tramite i DID) e le affermazioni su tale identità sono emesse e verificate indipendentemente dal luogo in cui vengono utilizzate. Un modo utile per pensarci: L'identità smette di essere un account memorizzato nel database di qualcun altro e diventa un insieme di dichiarazioni verificabili che si controllano e si riutilizzano.
Vediamo di analizzare la situazione rispetto ai modelli con cui già lavorate.
L'identità centralizzata è ancora l'impostazione predefinita ovunque. Una piattaforma possiede il record dell'utente, memorizza i suoi dati e agisce come autorità per la verifica. Se si desidera accedere, ci si autentica presso quel sistema. Tutto, compresi login, permessi e recupero, passa attraverso di esso.
Il problema non è solo la sicurezza (anche se le violazioni sono un problema costante). È l'architettura:
L'identità decentralizzata ribalta la situazione. Il sistema non ha bisogno di memorizzare i vostri dati. Ha solo bisogno di verificare le richieste presentate dall'utente. La fiducia passa da “abbiamo i vostri dati” a “possiamo verificare questa prova crittografica”.”
L'identità federata (OAuth, SAML, OpenID Connect) ha cercato di risolvere la frammentazione introducendo fornitori di identità, come Google, Microsoft o Apple, che garantiscono gli utenti tra i vari servizi.
Funziona, fino a un certo punto. Ma l'identità federata ha ancora una dipendenza centrale:
L'identità decentralizzata elimina questa dipendenza. Non c'è un singolo emittente che deve essere online al momento della verifica. Le credenziali sono verificate tramite firme, non tramite chiamate API. Ciò significa che:
È più simile a come funzionano le credenziali fisiche: non si chiama l'ufficio passaporti ogni volta che qualcuno controlla il documento d'identità.
Questi termini vengono spesso confusi. SSI è più che altro una filosofia di design: l'individuo controlla la propria identità, sceglie cosa condividere e non è vincolato a un fornitore. L'identità decentralizzata è lo stack tecnico che lo rende possibile:
È possibile implementare sistemi di identità decentralizzati che non sono completamente “auto-sovrani” (ad esempio, portafogli controllati dall'azienda o reti autorizzate). E si può parlare di SSI senza specificare l'infrastruttura. Nei sistemi reali, le due cose di solito convergono, ma è utile mantenere chiara la distinzione quando si progettano le architetture.
I portafogli sono il luogo in cui l'identità decentralizzata incontra i vincoli del mondo reale. In teoria, il controllo sull'identità deriva dal controllo delle chiavi crittografiche. In pratica, questo crea un problema che i sistemi tradizionali non hanno: cosa succede quando l'utente perde l'accesso?
Se una DID è legata a una chiave privata e questa viene persa, non esiste un meccanismo di recupero predefinito. Non esiste un flusso di “reset della password”, a meno che il sistema non sia esplicitamente progettato per supportarlo. La perdita della chiave può significare la perdita di controllo sull'identificatore e sulle credenziali ad esso collegate.
Ecco perché i sistemi di produzione introducono modelli di recupero e custodia in aggiunta al livello DID:
Il compromesso è inevitabile: più il controllo passa all'utente, più la responsabilità passa alla gestione delle chiavi. Per questo motivo, la maggior parte delle implementazioni nel mondo reale bilancia l'auto-sovranità con l'usabilità, invece di far ricadere la piena proprietà delle chiavi sull'utente.
Vale la pena di soffermarsi su questo punto, perché l'identità basata su DID diventa davvero efficace solo quando si separano le sue primitive fondamentali. L'identificatore non è la credenziale, la credenziale non è il portafoglio e il marcatore sulla catena non è l'identità stessa. Ogni livello ha una funzione distinta e questa separazione è ciò che fa funzionare il modello.
Questi due componenti costituiscono il nucleo del modello di identità decentralizzato. In alcuni sistemi, soprattutto in ambienti Web3, vengono utilizzati meccanismi aggiuntivi sulla catena per imporre l'accesso o i ruoli.
Gettoni legati all'anima (SBT) ne sono un esempio. Si tratta di token non trasferibili legati a un portafoglio e utilizzati per attività come il KYC gating, l'accreditamento o le autorizzazioni di protocollo. I contratti intelligenti possono controllarli direttamente.
Tuttavia, gli SBT non fanno parte dello stack di identità. Sono un livello di applicazione opzionale costruito sopra i segnali di identità e comportano dei compromessi: visibilità pubblica sulla catena, portabilità limitata e problemi di revoca e recupero delle chiavi.
I sistemi di identità tradizionali falliscono perché trattano la fiducia come un problema di archiviazione. Ogni piattaforma raccoglie le stesse prove grezze, come scansioni di passaporti, selfie e prove di indirizzo, e le archivia all'interno del proprio perimetro di conformità. Questo crea lo stesso problema ovunque: PII duplicate, portabilità debole, ampie superfici di violazione e flussi di onboarding che si appesantiscono senza migliorare di molto.
Nel modello tradizionale, i sistemi di identità accumulano rischi nel tempo. I fornitori di KYC, gli exchange, le app fintech, le piattaforme HR e i marketplace finiscono tutti per memorizzare più o meno lo stesso set di prove: documento d'identità governativo, scansione del volto, dati sull'indirizzo e metadati della sessione di verifica stessa.
Dal punto di vista dell'implementazione, il problema viene solitamente aggravato dalla proliferazione delle copie. Gli stessi dati degli utenti finiscono nei sistemi di onboarding, negli strumenti antifrode, nei livelli CRM, negli strumenti di supporto, nei data warehouse e negli archivi di conformità. Anche se lo stack di verifica principale è bloccato, i sistemi circostanti spesso non sono tenuti allo stesso standard.
L'identità tradizionale non offre all'utente quasi alcun controllo sullo stato di verifica. La piattaforma controlla il record, la politica di conservazione, il programma di riverifica e le regole di riutilizzo.
Ciò significa che l'utente non può portare la fiducia da un contesto all'altro. Il superamento del KYC sulla piattaforma A non serve a nulla sulla piattaforma B, perché il risultato della verifica è intrappolato all'interno del perimetro di conformità della piattaforma A. L'affermazione sottostante può essere ancora valida, ma non esiste un artefatto crittografico portatile su cui il verificatore successivo possa fare affidamento.
È qui che il modello inizia a rompersi dal punto di vista economico. Ogni piattaforma paga per ricostruire la fiducia da zero, perché l'identità viene memorizzata come dato interno, non emessa come prova riutilizzabile.
Il modello legacy, inoltre, rivela troppo per impostazione predefinita. Per dimostrare un fatto limitato, di solito si chiede agli utenti di rivelare l'intero documento sorgente che lo sottende.
Si tratta di un cattivo modello di privacy, ma anche di un cattivo modello di sistema. Una volta che l'identità è legata a registri basati sul conto e alla presentazione ripetuta di documenti, la correlazione diventa facile tra servizi, sessioni e controparti. Il verificatore ottiene più dati di quelli che gli servono, ne memorizza più di quelli che dovrebbe e aumenta la responsabilità senza migliorare proporzionalmente la qualità della fiducia.
Questa è la tassa operativa che tutti già conoscono. La stessa persona completa il KYC più volte perché ogni piattaforma gestisce il proprio stack di fiducia e non può consumare la verifica come credenziale portatile.
Se avete lavorato alla tokenizzazione, all'onboarding degli scambi o ai flussi di portafogli regolamentati, avete visto quanto questo sia dispendioso. Il collo di bottiglia è rappresentato dal fatto che la fiducia non può passare in modo pulito da un sistema all'altro, per cui ogni istituto ricostruisce la stessa pipeline di verifica attorno al proprio confine di database.
E anche le credenziali verificabili non risolvono il problema da sole. Una firma valida dimostra solo che una richiesta di risarcimento è stata emessa da un soggetto specifico. Non prova che questa persona avesse l'autorità per emettere quella richiesta. Questa è la parte che molti piloti DID sottovalutano. I verificatori devono sapere quali emittenti sono legittimi, quali schemi di credenziali sono accettati e in base a quali regole si può fare affidamento su una richiesta.
In produzione, questo viene gestito attraverso i framework di fiducia: eIDAS 2.0 liste fiduciarie nell'UE, Stile VICAL coordinamento fiduciario per le patenti di guida mobili secondo la norma ISO 18013-5, Federazione OpenID catene fiduciarie e registri nazionali di fornitori di servizi fiduciari.
Senza questo livello, non si ottiene un'identità riutilizzabile. Si ottengono credenziali che si verificano dal punto di vista matematico, ma che non significano nulla dal punto di vista operativo. La firma è valida. Manca la fiducia.
"Perché il modello di identità decentralizzata funziona? Perché dà a ciascuna parte meno da memorizzare, meno da esporre e meno da ricontrollare. L'utente riutilizza una prova affidabile, il verificatore ottiene solo le richieste di cui ha bisogno e la piattaforma evita di diventare un'altra cassaforte di PII. In Innowise, ciò significa di solito credenziali fuori dalla catena per la portabilità, attestazioni sulla catena per il controllo dell'accesso e divulgazione selettiva per i controlli sensibili alla privacy."
Esperto di Blockchain e analista DeFi
Basta con le definizioni. Ciò che conta è il percorso di verifica: come un DID diventa risolvibile, come un emittente vi lega una richiesta e come tale richiesta viene verificata in seguito senza dover ricorrere a un registro centrale. Esaminiamo il flusso da un capo all'altro.
Un DID diventa utile solo quando può essere risolto. Viene generato con materiale chiave e pubblicato secondo un metodo DID. La risoluzione restituisce il documento DID, che espone le chiavi pubbliche e i metodi di verifica utilizzati da altri per convalidare le firme.
Una volta che il soggetto ha un DID, l'emittente può allegare un claim firmato come credenziale verificabile. L'emittente esegue prima i suoi controlli, quindi firma una credenziale che lega l'asserzione all'identificatore del soggetto. Ciò che avanza non è un'evidenza grezza, ma un risultato attestato.
Il titolare conserva la credenziale, di solito in un portafoglio, e la presenta quando è necessaria una prova. A seconda dello stack, può trattarsi della credenziale completa o di una prova derivata. Il punto è il riutilizzo: il titolare presenta una richiesta già verificata invece di ricominciare l'onboarding.
Il verificatore controlla la firma dell'emittente, conferma il binding del soggetto e valuta lo stato della credenziale, come la scadenza o la revoca. A tal fine, risolve il DID dell'emittente e recupera la chiave pubblica dal documento DID. Non è richiesto alcun callback dell'emittente.
Un DID diventa utile solo quando può essere risolto. Viene generato con materiale chiave e pubblicato secondo un metodo DID. La risoluzione restituisce il documento DID, che espone le chiavi pubbliche e i metodi di verifica utilizzati da altri per convalidare le firme.
Una volta che il soggetto ha un DID, l'emittente può allegare un claim firmato come credenziale verificabile. L'emittente esegue prima i suoi controlli, quindi firma una credenziale che lega l'asserzione all'identificatore del soggetto. Ciò che avanza non è un'evidenza grezza, ma un risultato attestato.
Il titolare conserva la credenziale, di solito in un portafoglio, e la presenta quando è necessaria una prova. A seconda dello stack, può trattarsi della credenziale completa o di una prova derivata. Il punto è il riutilizzo: il titolare presenta una richiesta già verificata invece di ricominciare l'onboarding.
Il verificatore controlla la firma dell'emittente, conferma il binding del soggetto e valuta lo stato della credenziale, come la scadenza o la revoca. A tal fine, risolve il DID dell'emittente e recupera la chiave pubblica dal documento DID. Non è richiesto alcun callback dell'emittente.
Una volta che il flusso è chiaro, si presentano le vere questioni di progettazione: come vengono utilizzati gli identificatori e come vengono gestite le chiavi nel tempo.
Una DID pubblica è stabile e scopribile. Gli emittenti lo usano di solito perché i verificatori hanno bisogno di un modo coerente per risolvere le chiavi e convalidare le firme. Una DID a coppie, invece, viene generata per ogni relazione. Lo stesso utente presenta identificatori diversi a verificatori diversi, il che impedisce la correlazione tra servizi.
Questa scelta non è estetica. Il riutilizzo di un singolo DID tra i vari servizi rende banale il collegamento. I DID accoppiati interrompono il collegamento a livello di identificatore.
Poi c'è la gestione delle chiavi, che è il punto in cui la maggior parte dei sistemi si scontra con la produzione. Un DID è affidabile quanto le chiavi che vi stanno dietro, quindi è necessario pianificare:
In pratica, è qui che risiede la complessità. La verifica della firma è semplice. Mantenere gli identificatori utilizzabili, recuperabili e non correlabili nel tempo è il problema ingegneristico più difficile.
Una volta superato il flusso, la domanda successiva è come gli identificatori vengono effettivamente risolti e mantenuti. Questo si riduce a due cose: il Struttura del documento DID e il Metodo DID che definisce come viene creato, aggiornato e risolto.
Un documento DID è l'output di risoluzione di un DID. Indica ai verificatori quali chiavi, controllori ed endpoint di servizio sono autorizzati per quell'identificatore. In pratica, non è un profilo utente. È un descrittore di verifica.
Campi fondamentali di cui ci si interessa abitualmente:
Il punto di implementazione della chiave rimane lo stesso: un verificatore risolve il DID, seleziona il metodo di verifica appropriato e controlla se la chiave è autorizzata per l'operazione in corso.
Finora abbiamo parlato dell'identità come qualcosa che una persona controlla. Nei sistemi B2B, il soggetto chiave è spesso un'organizzazione. Le banche, i fornitori di servizi logistici e le piattaforme RWA hanno bisogno di verificare non solo i dati personali, ma anche i dati personali. che firmato qualcosa, ma se quella persona fosse autorizzata ad agire per conto di una società.
È qui che i DID organizzativi diventano più complessi. Il controllo è distribuito tra ruoli, sistemi di custodia, politiche di firma e regole di delega. Una configurazione di produzione deve definire chi può firmare, cosa può firmare e come revocare tale autorità.
In pratica, ciò può comportare vLEI da GLEIF per l'identità delle persone giuridiche, portafogli aziendali con Firma supportata da HSM, e catene di capacità di autorizzazione come ZCAP-LD.
I documenti DID non sono statici. Le chiavi scadono, i dispositivi vengono smarriti, l'infrastruttura di firma cambia e le chiavi dell'emittente devono essere ruotate. Un progetto DID serio deve gestire tutto questo senza interrompere le credenziali esistenti.
La rotazione delle chiavi di solito significa aggiungere un nuovo metodo di verifica, cambiare la chiave autorizzata per una determinata relazione e ritirare la vecchia chiave. Ma il dettaglio che conta è scopo. Rotazione di un autenticazione influisce sui flussi di login o di sfida-risposta. La rotazione di una metodo di asserzione chiave influisce sull'emissione e sulla verifica delle credenziali.
Il percorso di aggiornamento dipende dal metodo DID. Con did:web, si aggiorna il documento DID ospitato. Con did:ethr, si pubblica una transazione nel registro. La parte difficile è la continuità: i verificatori devono sapere quale chiave era valida quando è stata emessa una credenziale e se questa credenziale è stata revocata, scaduta o sostituita.
Questo ci porta ai metodi DID, perché il metodo definisce esattamente il modo in cui creazione, risoluzione, aggiornamento e disattivazione funzionano nel sistema reale.
Un metodo DID è il livello di implementazione dietro la sintassi standard DID.
Definisce le regole per:
In altre parole, la sintassi DID è standard (did:metodo:identificatore), ma il metodo dà forma all'intero modello di infrastruttura che sta dietro al DID.
Questi tre metodi coprono la maggior parte dei casi d'uso reali:
Ora la tabella fornisce la meccanica. La parte più difficile è decidere con quale modalità di fallimento si può convivere: dipendenza dal DNS, costo della catena, assenza di rotazione, verificabilità pubblica o portabilità più debole. Ecco quindi la mia opinione su come scegliere.
Prima di scegliere, ponete le domande più brutte sulla produzione:
Nelle implementazioni reali, di solito si mescolano i metodi. Gli emittenti spesso usano did:web o did:ethr; I titolari utilizzano identificatori a coppia o effimeri. Questa suddivisione mantiene stabile la fiducia dell'emittente e riduce il rischio di correlazione per gli utenti.
Chiariamo subito questo punto: non è necessaria una blockchain per implementare l'identità decentralizzata. Le specifiche DID Core del World Wide Web Consortium non lo richiedono e molti sistemi di produzione funzionano interamente fuori dalla catena.
Perché si parla di blockchain? Perché risolve molto bene un problema specifico: fiducia condivisa senza un proprietario centrale. Non l'archiviazione, non l'identità in sé, ma il coordinamento di chiavi, identificatori e status.
Nei sistemi basati su DID, la blockchain funge da registro pubblico, resistente alle manomissioni. A seconda del metodo, può essere utilizzato per:
Il punto chiave: la blockchain non verifica l'identità. Sta fornendo un punto di riferimento comune su cui i verificatori possono fare affidamento senza fidarsi di una singola parte.
Ad esempio, con did:ethr, Il DID si risolve con i dati della catena. Il verificatore si fida dello stato della catena, non dell'infrastruttura dell'emittente.
È qui che molte implementazioni di DID vanno male. La blockchain è utile per lo stato condiviso, ma è un luogo terribile per i dati di identità grezzi. Non si mettono passaporti, dati biometrici, credenziali complete o dati personali sulla catena. Si usa la catena per il materiale di prova e i dati di coordinamento, quindi si tengono i payload sensibili dell'identità fuori dalla catena.
Una scissione pulita si presenta di solito in questo modo:
A catena:
Fuori catena:
Il motivo è semplice: privacy e costi. Le blockchain sono pubbliche, permanenti e costose da aggiornare. I dati di identità necessitano di privacy, cancellazione, correzione e controllo degli accessi. Queste due cose non vanno d'accordo.
La blockchain viene solitamente utilizzata per l'ancoraggio, non per l'archiviazione. Si impegna una piccola prova di stato nella catena, come l'hash di un documento DID, l'aggiornamento del registro dell'emittente, il riferimento allo stato delle credenziali o l'evento di rotazione delle chiavi, mentre i dati reali dell'identità rimangono fuori dalla catena.
Ciò conferisce ai verificatori tre utili proprietà:
Il compromesso è la permanenza. Se si inseriscono nella catena i dati sbagliati, non è possibile rimuoverli in modo pulito. Ecco perché i sistemi DID maturi conservano hash, riferimenti e transizioni di stato, non credenziali complete, documenti o dati personali.
La blockchain è lo strumento sbagliato quando non rimuove una dipendenza fiduciaria. Se la stessa organizzazione controlla l'emittente, il verificatore e l'applicazione, l'inserimento dello stato DID nella catena di solito aggiunge solo costi, latenza e rumore operativo.
Saltare la blockchain quando:
Ecco perché did:web funziona così bene per molti flussi di identità aziendali. Mantiene il modello DID, ma utilizza l'infrastruttura web esistente invece di forzare ogni aggiornamento attraverso una transazione blockchain.
Usate la blockchain quando parti indipendenti hanno bisogno di uno stato condiviso che possono verificare senza fidarsi del vostro server. Altrimenti, tenetelo fuori dalla catena. Una maggiore decentralizzazione sulla carta non significa automaticamente una migliore architettura dell'identità.
In sistemi come il portafoglio di identità digitale dell'UE o le patenti di guida mobili (ISO 18013-5), la PKI è stata scelta in gran parte perché le reti pubbliche L1/L2 non soddisfano i requisiti fondamentali dell'identità: privacy, sovranità dei dati e controllo normativo. I dati di identità non possono essere replicati pubblicamente e le giurisdizioni hanno bisogno di un controllo rigoroso sul luogo in cui i dati vengono elaborati e conservati.
Ma le architetture più recenti introducono una terza opzione: sistemi zk-L2 autorizzati. Questi combinano:
L'idea chiave è la separazione dei problemi a livello di infrastruttura:
In questo modo si evita un limite fondamentale delle catene pubbliche: l'esposizione dei dati. Allo stesso tempo, evita un limite delle PKI pure: la dipendenza da gerarchie di fiducia chiuse e prive di verificabilità condivisa.
Un'altra proprietà importante è architettura multidominio. Diversi attori - ministeri, autorità di regolamentazione, banche o regioni - possono operare in zone di esecuzione separate con i propri confini di conformità, pur contribuendo a uno stato verificabile condiviso attraverso le prove.
Questo amplia lo spazio di progettazione dei sistemi di identità. Invece di scegliere tra PKI centralizzata e blockchain pubblica, le nuove implementazioni possono combinare privacy, conformità e fiducia condivisa in un unico modello.
Ok, a questo punto dovrebbe essere chiaro cosa i DID fanno di diverso rispetto al KYC standard. Ma la domanda più pratica è: cosa cambia effettivamente per me? Domanda corretta. Da quello che ho visto nelle implementazioni reali, l'impatto dipende molto da quale parte si sta, quindi vale la pena di suddividerlo.
Per gli utenti, il cambiamento più importante è il controllo su quando e come viene condivisa l'identità.
In pratica, questo trasforma l'identità da qualcosa che si ripropone costantemente in qualcosa che si presente quando necessario.
Per le organizzazioni, il cambiamento riguarda meno la UX e più la rischio e struttura dei costi.
Ciò che cambia dal punto di vista operativo è questo: si smette di essere un custode di dati e si inizia ad essere un verificatore di sinistri.
Per gli sviluppatori, il valore è in come è strutturata la logica dell'identità.
Da un punto di vista ingegneristico, si passa dalla “gestione di utenti e sessioni” alla "gestione delle sessioni". verificare le prove e applicare le condizioni.
Abbandoniamo per un attimo la teoria e affrontiamo la questione come se si trattasse di un sistema reale. Che cosa fa DID in realtà sentirsi come nella pratica? Dove smette di essere un diagramma e inizia a essere qualcosa che si spedisce?
Noterete una cosa: gli oggetti cambiano - diploma, storia lavorativa, stato del KYC - ma il flusso non cambia quasi mai.
Supponiamo che vi siate appena laureati e che dobbiate dimostrare la vostra laurea a un futuro datore di lavoro. Il percorso abituale è maldestro: caricare un PDF, allegare una scansione, magari aspettare che qualcuno invii un'e-mail all'ufficio di registrazione. Funziona, ma a malapena. L'intero processo dipende dalla fiducia manuale.
Con una credenziale basata su DID, l'università rilascia una credenziale verificabile al momento della laurea. Si trova nel vostro portafoglio, firmata da una chiave pubblicata nel documento DID dell'università.
Mesi dopo, si fa domanda per un lavoro. Il datore di lavoro non ha bisogno di contattare l'università. Voi presentate le credenziali e il loro sistema le verifica:
Questo è il bello del modello: l'università firma una volta sola, si riutilizza la prova e ogni verificatore può controllarla in modo indipendente.
Quanto ci si può fidare di un CV? I titoli si gonfiano. Le date si confondono. “A capo di un team” può significare qualsiasi cosa, dalla gestione di dieci persone alla gestione di stand-up.
Ora capovolgiamo il modello. Quando lasciate un'azienda, questa vi rilascia una credenziale:
La prossima volta che qualcuno vi chiederà: “Puoi dimostrare di aver fatto X?”, non spiegate. Presentate. E no, questo non significa esporre ogni volta l'intera storia lavorativa. Con il giusto formato di credenziale, il titolare può dimostrare un'affermazione più ristretta, come ad esempio:
...senza consegnare l'intera storia lavorativa. È una posizione molto diversa da quella di “inviateci il vostro CV completo e le vostre referenze”.”
Qui l'identità riutilizzabile diventa ovvia. Si verifica una volta con un fornitore affidabile: passaporto controllato, controllo delle sanzioni superato, giurisdizione confermata. Il fornitore rilascia una credenziale KYC al vostro portafoglio.
La prossima piattaforma? Si presentano le credenziali invece di caricare nuovamente gli stessi documenti. La piattaforma controlla:
Alcuni team di tokenizzazione utilizzano anche gettoni legati all'anima come marcatori KYC sulla catena: questo indirizzo ha superato il controllo richiesto. I dati sull'identità rimangono fuori dalla catena; la catena trasporta solo il segnale di idoneità.
Utile, ma solo se il marcatore è ampio, revocabile e non rappresenta una perdita permanente di privacy.
Nel settore sanitario l'architettura DID ha bisogno di un guinzaglio corto. Supponiamo che una clinica vi dia una credenziale di vaccinazione, un laboratorio firmi i risultati delle vostre analisi del sangue e il vostro medico rilasci una credenziale di prescrizione. Le tenete nel vostro portafoglio invece di lasciare che ogni record scompaia in un altro portale.
Poi si cambia medico. Aspettate che un sistema parli con un altro? Si devono rincorrere i PDF? No. Si condivide la credenziale specifica di cui ha bisogno il nuovo fornitore. Loro verificano l'emittente, la firma e lo stato.
Per essere chiari: nulla di tutto ciò richiede l'inserimento dei dati medici nella catena. La catena è per gli identificatori, le chiavi, forse i registri di stato. I dati sensibili restano fuori dalla catena. Se questo confine non viene rispettato, il progetto non è valido.
Ora allontaniamoci dalle persone. Prendete un prodotto, ad esempio una bottiglia di olio d'oliva. Etichetta pregiata, bella confezione. È vero? Invece di fidarsi del marchio, si tocca il telefono su un tag NFC. Dietro l'etichetta c'è un DID legato al lotto del prodotto.
Ciò che si ottiene è un dato firmato:
È possibile seguire letteralmente il prodotto dalla fonte allo scaffale. Risolve tutto? No. Se il primo inserimento di dati è sbagliato, tutto ciò che segue conserva l'errore. Ma almeno ora sapete che firmato ogni passo. È un grande passo avanti rispetto a “fidati di noi”.”
Il governo è il punto in cui l'identità in stile DID esce dalla bolla delle criptovalute. Un punto di riferimento importante è il portafoglio di identità digitale dell'UE nell'ambito di eIDAS 2.0, un'iniziativa su larga scala che mira a fornire portafogli a cittadini, residenti e imprese in tutti gli Stati membri.
Ma il panorama più ampio è più variegato. Alcuni dei sistemi di identità digitale più grandi e maturi a livello globale non sono strettamente basati sulla DID, ma seguono schemi simili che prevedono credenziali riutilizzabili e dati controllati dal titolare:
Il cambiamento comune a tutti questi sistemi è lo stesso: passare da registri di identità centralizzati a prove riutilizzabili e presentate dall'utente. Allo stesso tempo, è importante separare i modelli di fiducia. Sistemi come eIDAS si basano su PKI federate e liste di servizi di fiducia, mentre i sistemi basati su DID si basano su identificatori crittografici e credenziali verificabili. In pratica, questi modelli spesso coesistono piuttosto che sostituirsi l'un l'altro.
Finora tutto funziona bene all'interno di un singolo sistema. Ma cosa succede quando le credenziali attraversano i confini del sistema? È qui che le cose si fanno difficili. Servono standard condivisi, in modo che i dati abbiano senso ovunque, e serve una governance, in modo che i verificatori sappiano di quali emittenti fidarsi. Ecco gli standard e i livelli di governance più importanti.
Gli standard rendono le credenziali interoperabili. La governance le rende accettabili. Senza standard, nulla si analizza. Senza governance, nulla è affidabile. I sistemi reali funzionano solo quando entrambi i livelli sono definiti insieme.
Gli standard dicono come deve comportarsi un sistema DID. La produzione vi dice dove si fa confusione. Oggi, la maggior parte dei rischi non deriva dalla sintassi DID o dagli algoritmi di firma in sé. Si manifestano invece nei portafogli, nel recupero delle chiavi, nella revoca, nell'interoperabilità e nel fatto che un numero sufficiente di emittenti e verificatori sia effettivamente d'accordo nell'utilizzare lo stesso modello di fiducia.
Nei sistemi DID, l'identità dipende dal controllo delle chiavi. È potente, ma non perdona. Se un utente perde la chiave, il recupero non è automatico. Se un aggressore ottiene la chiave, può impersonare il titolare. Ecco perché le implementazioni serie raramente si affidano alla sola frase seme grezza. Di solito hanno bisogno di MPC, di recupero sociale, di chiavi supportate da hardware o di un modello di custodia ibrido.
Le credenziali invecchiano. Il KYC scade, i dipendenti lasciano, le licenze vengono sospese. Quindi la verifica non può fermarsi a “la firma è valida?”. Il verificatore controlla lo stato della credenziale al momento dell'utilizzo. Di solito si tratta di elenchi di stato, registri di revoca o credenziali di breve durata. Se si tralascia questa parte, le vecchie credenziali continuano a sembrare valide.
Gli standard aiutano, ma non rendono magicamente compatibili tutti i portafogli, gli emittenti e i verificatori. Uno stack può utilizzare credenziali JSON-LD, un altro può preferire i metodi JWT. Metodi DID. I protocolli di presentazione differiscono. Quindi sì, l'ecosistema si sta muovendo verso l'interoperabilità, ma i progetti reali necessitano ancora di un lavoro di integrazione e di scelte di profilo rigorose.
La parte più difficile è il coordinamento. Un sistema DID ha bisogno di emittenti di cui ci si fidi, di verificatori disposti ad accettare le credenziali, di utenti in grado di gestire i portafogli e di regole di governance che tutti comprendano. Finché questi elementi non si allineano, l'adozione avverrà per settori: finanza regolamentata, tokenizzazione, credenziali per la forza lavoro, ID governativi ed ecosistemi chiusi.
La maggior parte dei sistemi DID oggi si basa sulla crittografia a curva ellittica: Ed25519, secp256k1 o P-256. Questi schemi sono ampiamente diffusi, ma non sono sicuri per il post-quantum. Un computer quantistico sufficientemente potente potrebbe decifrarli con l'algoritmo di Shor, rendendo la falsificazione delle firme un rischio reale a lungo termine.
Questo è importante perché le credenziali di identità spesso vivono per anni. I diplomi, le licenze e le attestazioni legali rilasciati oggi potrebbero dover essere verificati anche molto tempo dopo che la crittografia che li sottende si sarà esaurita.
Gli standard si stanno già muovendo in questa direzione. Il NIST ha finalizzato schemi di firma post-quantistica come ML-DSA (Dilithium) e SLH-DSA (SPHINCS+), mentre l'ecosistema DID/VC sta esplorando firme ibride e cripto-agilità.
I sistemi DID devono supportare più metodi di verifica, nuove suite di firma e percorsi chiari di rotazione delle chiavi fin dal primo giorno. Le firme post-quantum sono molto più grandi delle firme Ed25519 o ECDSA, il che influisce sulle presentazioni QR, sui registri e sui meccanismi di stato della catena. Ma per le identità governative e aziendali di lunga durata, la cripto-agilità è un must.
L'errore più frequente è quello di considerare la DID come qualcosa da “aggiungere” a uno stack di identità esistente. In pratica, si tratta di un cambiamento nel modo di modellare la fiducia, il flusso di dati e la responsabilità. Le parti tecniche sono raramente la parte più difficile. La maggior parte dei progetti ha successo o fallisce grazie al coordinamento, alla governance e all'integrazione.
Iniziate a identificare i luoghi in cui memorizzate i dati di identità per poi verificarli in seguito: Stato KYC, età, occupazione, licenze, accreditamento e diritti di accesso. L'obiettivo è quello di memorizzare meno dati grezzi e verificare più dichiarazioni firmate. In questo modo si riduce la responsabilità, si semplifica la conformità e si rende l'identità trasferibile tra i vari sistemi.
Prima di scegliere gli strumenti, definire il modello di fiducia in termini concreti. Nei progetti reali, ciò si traduce tipicamente in:
In mancanza di ciò, si ottengono credenziali che vengono verificate correttamente ma non accettate dai verificatori.
Ora scegliete lo stack tecnico. Scegliete il metodo DID, il formato delle credenziali, il flusso del portafoglio e il modello di revoca. did:web di solito si adatta ai flussi aziendali e SaaS. did:ethr si adatta all'applicazione dei contratti intelligenti e all'identità sulla catena. did:key si adatta a identificatori locali o di breve durata.
Non scegliete l'opzione più “decentralizzata”. Scegliete quella che corrisponde al vostro confine di fiducia.
Non iniziare con “identità per tutto”. Iniziate con un flusso in cui il dolore è chiaro. I buoni piloti includono:
Stabilire un ambito preciso: un tipo di credenziale, uno o due emittenti, un flusso di verificatori, regole di revoca chiare. Evitare di iniziare con:
Dimostrare il flusso end-to-end, quindi espandere.
Una volta passati da un progetto pilota alla produzione, il rilascio delle credenziali è solo metà del problema. La domanda più difficile è cosa succede quando una credenziale non è più affidabile: un controllo KYC scade, un dipendente lascia, una licenza viene sospesa o un portafoglio viene compromesso.
Non esiste un unico approccio standard e ogni modello comporta dei compromessi:
I diversi ecosistemi adottano approcci diversi. Ad esempio, le patenti mobili ISO 18013-5 si basano sulla convalida dell'emittente e sugli elenchi di fiducia piuttosto che sulla revoca in stile W3C. Senza una chiara strategia di revoca, il modello della “credenziale riutilizzabile” si rompe. Una credenziale compromessa può continuare a essere presentata a meno che il suo stato non venga controllato attivamente.
Un tipico progetto DID/VC si svolge per fasi. Un progetto pilota di solito richiede 3-4 mesi e convalida un caso d'uso end-to-end, tipicamente nell'ambito di $150K–$300K, a seconda della portata. L'avvio della produzione richiede 9-12 mesi e si espande a più emittenti, verificatori e tipi di credenziali, che di solito vanno dal Da $800K a $2M+, a seconda della complessità dell'integrazione e dei requisiti di conformità.
Un team tipico comprende:
In pratica, la complessità è raramente nella crittografia. È nell'integrazione, nella governance e nell'esperienza dell'utente.
Per concludere, facciamo un po' di zoom. L'identità basata sui DID non è uno stack finito. È ancora in evoluzione, soprattutto per quanto riguarda i sistemi di prova, l'infrastruttura dei portafogli, i livelli di interoperabilità e l'integrazione normativa. Da quello che vedo nelle implementazioni reali, alcune direzioni stanno diventando chiare.
L'identità riutilizzabile è l'ovvio punto di arrivo, ma il collo di bottiglia non è la verifica della firma. Quella parte funziona già. La parte più difficile è la fiducia dell'emittente, gli schemi delle credenziali e le regole di accettazione.
In futuro, una credenziale KYC emessa in un ambiente regolamentato dovrebbe essere riutilizzabile tra le borse, le piattaforme di tokenizzazione, i prodotti di prestito e le interfacce DeFi conformi, a condizione che il DID dell'emittente sia risolvibile, lo schema sia compreso e il verificatore accetti l'emittente nell'ambito del proprio quadro di fiducia. È qui che sta il vero lavoro: non dimostrare la validità di una firma, ma concordare il reale significato della richiesta firmata.
Oggi, molti sistemi rivelano ancora gli attributi. Il futuro è dimostrare le condizioni. Invece di mostrare la data di nascita, si dimostra che si è maggiorenni. Invece di esporre tutti i dati KYC, si dimostra di aver superato una politica di conformità definita. Invece di condividere un campo di giurisdizione, si dimostra l'idoneità a una transazione.
Tecnicamente, ciò indica le firme BBS+ per la divulgazione selettiva e le zk-SNARK o zk-STARK per le prove dei predicati. Il verificatore controlla la prova con le chiavi pubbliche controllate dall'emittente, mentre i dati personali sottostanti rimangono nascosti. Questo cambia il modello di privacy da “condividere meno dati” a “non condividere affatto i dati quando una prova è sufficiente”.”
L'interoperabilità deciderà se l'identità decentralizzata rimarrà frammentata o diventerà un'infrastruttura utilizzabile.
I punti deboli sono ancora noti: Credenziali JSON-LD vs JWT, metodi DID diversi, protocolli wallet diversi, flussi di presentazione diversi. Ecco perché i sistemi di produzione definiscono sempre più spesso profili rigorosi: formati di credenziali approvati, metodi DID supportati, emittenti affidabili e protocolli di presentazione accettati.
Nel corso del tempo, mi aspetto una maggiore convergenza sui flussi da portafoglio a verificatore, sullo scambio di presentazioni e sui registri di fiducia. Senza di essi, ogni progetto DID diventa un'altra isola di identità. Con questo sistema, le credenziali possono essere trasferite da una piattaforma all'altra senza bisogno di integrazioni personalizzate ogni volta.
La regolamentazione sta trasformando l'identità decentralizzata da opzione tecnica a infrastruttura pubblica.
Nell'UE, eIDAS 2.0 e il portafoglio di identità digitale dell'UE sono il segnale più importante. Gli Stati membri sono tenuti a fornire l'infrastruttura del portafoglio, con credenziali per gli attributi di identità, le licenze, le qualifiche e i casi d'uso del settore pubblico-privato. Questo crea un livello di credenziali regolamentato in tutta Europa.
Negli Stati Uniti, il National Institute of Standards and Technology sta aggiornando le linee guida sull'identità digitale (ad esempio, NIST 800-63) per tenere conto delle credenziali crittografiche, dei livelli di garanzia e della verifica che preserva la privacy. Gli Stati Uniti probabilmente manterranno un modello più orientato al mercato, mentre l'UE spinge per un quadro coordinato di portafogli.
Dove si va quindi? Verso un minor numero di documenti caricati, più credenziali riutilizzabili, più controlli crittografici locali e una divulgazione più selettiva. I vincitori non saranno i sistemi che conservano il maggior numero di dati sull'identità. Saranno quelli in grado di verificare la giusta richiesta con la minore esposizione possibile.
Un identificatore decentralizzato è un identificatore unico e risolvibile che punta a un documento DID contenente chiavi pubbliche e metodi di verifica. Consente alle entità di dimostrare l'identità o il controllo senza affidarsi a un'autorità centrale. In pratica, sostituisce la consultazione di un database con una verifica crittografica.
Un DID si risolve in un documento DID con chiavi pubbliche. Un emittente firma una credenziale, un titolare la memorizza e un verificatore controlla la firma e lo stato utilizzando il DID dell'emittente. Non è necessaria una chiamata diretta all'emittente. Questo rende la verifica portatile e indipendente da ogni singolo sistema.
L'identità decentralizzata è il modello generale di emissione e verifica dei crediti senza archiviazione centrale. Il DID è solo un componente di questo modello. Agisce come livello di identificazione utilizzato per risolvere le chiavi e verificare le firme. Senza DID, il sistema non avrebbe un modo coerente per individuare e fidarsi del materiale di verifica.
Non necessariamente. Alcuni metodi DID utilizzano blockchain per la risoluzione o l'ancoraggio, ma molti, come did:web, si basano su un'infrastruttura web standard. Il DID stesso è un riferimento, non un record di dati. Ciò che può essere memorizzato sulla catena sono chiavi, hash o riferimenti di stato, non dati di identità.
Vengono utilizzati per collegare le identità alle chiavi crittografiche, consentire credenziali verificabili, supportare KYC riutilizzabili, la verifica della forza lavoro, gli ID digitali e il controllo degli accessi nei sistemi basati su web e blockchain. Il loro ruolo è quello di rendere la verifica dell'identità trasferibile tra i vari sistemi.
Si genera una coppia di chiavi e si crea un DID secondo un metodo scelto. Quindi lo si pubblica o registra in modo che possa essere risolto in un documento DID. Il processo esatto dipende dal metodo DID (ad esempio, web, blockchain o basato su chiavi). Il metodo determina il modo in cui il DID viene ancorato, aggiornato e risolto.
Esperto di Blockchain e analista DeFi
Andrew traduce concetti decentralizzati in strumenti finanziari sicuri e funzionali. Naviga nel volatile panorama della DeFi per costruire infrastrutture blockchain scalabili che rispondano all'utilità del mondo reale, andando oltre le parole d'ordine per fornire valore tecnico.
