did:web spiegato
Ogni credential digitale è firmato da qualcuno, e un verificatore deve poter risalire a chi sia e a quali chiavi stia usando oggi. did:web risponde a questo con l'infrastruttura che quasi ogni organizzazione possiede già: il proprio nome di dominio. L'identificatore dice a quale dominio chiedere, la risposta è un normale file servito via HTTPS, e non serve che esista nient'altro perché funzioni.
Che cos'è davvero did:web
Una DID è un identificatore permanente che chiunque può consultare per trovare le chiavi pubbliche di chi la detiene. Un metodo DID è la regola che descrive quella consultazione, e ne esistono decine. Alcuni scrivono la registrazione su una blockchain, altri su una rete costruita apposta, e ciascuno obbliga il verificatore a imparare come funziona quel particolare sistema.
did:web prende la strada opposta. La consultazione è una richiesta HTTPS al dominio indicato nell'identificatore, e la registrazione è un file JSON che il titolare del dominio pubblica e modifica come qualsiasi altra pagina del suo sito. Non c'è una rete a cui aderire, né un registro su cui scrivere, né una tariffa da pagare.
Per questo compare così presto in quasi ogni progetto. Un team in grado di pubblicare un file sul proprio server web può emettere e verificare credential lo stesso pomeriggio, e l'identificatore che ne risulta è una DID vera, accettata da qualsiasi wallet o verificatore conforme, non un ripiego da sostituire in seguito.
Come l'identificatore diventa un URL
La corrispondenza è meccanica, ed è proprio questo il punto. Un dominio nudo porta a un file nella directory well-known che i siti già usano per i metadati leggibili dalle macchine. Aggiungendo dopo il dominio segmenti separati dai due punti, questi diventano segmenti di percorso, così una sola organizzazione può pubblicare un identificatore distinto per reparto, per ambiente o per servizio di emissione senza registrare nulla di nuovo.
Due dettagli sfuggono spesso. Un numero di porta impone di codificare in percentuale i suoi due punti, perché i due punti semplici separano già le parti dell'identificatore. E il file deve essere servito via HTTPS con un certificato che si convalida, dato che il trasporto è l'unica cosa che si frappone tra un verificatore e una risposta contraffatta.
L'identificatore che qualcuno vi consegna
did:web:example.com:issuer:euL'URL HTTPS a cui corrisponde, senza alcun servizio di lookup nel mezzo
https://example.com/issuer/eu/did.jsonIl DID document restituito, con le chiavi e gli endpoint
{ "id": "did:web:example.com:issuer:eu", "verificationMethod": [ ... ] }
Perché le organizzazioni lo scelgono
La prima ragione è la riconoscibilità. Un verificatore che vede un identificatore puntare al dominio di un'azienda può controllare, nel modo più immediato che esista, che il nome sul credential corrisponda al nome sul sito. Non c'è nessuna visura a registro né catena di certificati da spiegare a qualcuno perché la cosa arrivi.
La seconda è che gestirlo non costa nulla. Il documento sta dietro lo stesso hosting, lo stesso monitoraggio e lo stesso processo di modifica del resto del sito. Non c'è un sistema separato da finanziare, da mantenere disponibile o da spiegare a un revisore, e ruotare una chiave è un rilascio anziché una transazione.
La terza è la portabilità. Poiché ogni libreria di wallet e di verifica lo supporta, did:web è il metodo che ha più probabilità di funzionare con un partner con cui non avete mai integrato, il che ne fa la scelta naturale per progetti pilota, ambienti di test e gli eventi di interoperabilità in cui si incontrano le implementazioni europee di wallet.
Dove did:web si ferma
Tutto ciò che il metodo vi dà poggia sul dominio. Chi controlla la registrazione, i name server e il certificato controlla l'identificatore, perciò un rinnovo scaduto, un account DNS dirottato o un certificato emesso per errore bastano a parlare a vostro nome. Sotto non c'è una seconda firma su cui ripiegare.
Non ha nemmeno memoria. Un verificatore vede il documento com'è in questo istante e non ha modo di sapere che cosa dicesse la settimana scorsa, quindi una chiave sostituita è indistinguibile da una ruotata. did:webvh esiste esattamente per questo: lo stesso hosting web, più un registro firmato di ogni modifica a cui si può solo aggiungere, così che un verificatore possa seguire la storia dalla prima voce fino allo stato attuale.
E non è un controllo di identità. Pubblicare un documento sotto un dominio dimostra il controllo di quel dominio e nient'altro. Quando un verificatore deve sapere che una persona giuridica è davvero chi dichiara di essere, quella garanzia viene da una Trusted List, da un certificato qualificato o da un Trust Framework costruito allo scopo, mentre il metodo DID porta soltanto le chiavi sottostanti.
Che cosa significa per te
Emittente
Trattate il documento come infrastruttura di produzione fin dal primo giorno. Mettetelo sotto controllo delle modifiche, verificate che l'URL risponda e che il certificato sia valido, e lasciate elencata una chiave dismessa per la verifica finché è in uso qualcosa che ha firmato.
Parte affidante
Recuperare il documento non equivale a fidarsene. Decidete separatamente quali domini accettate, rifiutate tutto ciò il cui certificato non si convalida e usate la cache con attenzione: una copia obsoleta tiene in vita una chiave revocata, una copia mancante fa cadere il vostro servizio insieme a quello della controparte.
Titolare del wallet
Il dominio nell'identificatore di un emittente merita uno sguardo. È l'unica parte di un credential che potete leggere senza strumenti, e un nome che non corrisponde all'organizzazione attesa è una ragione per fermarsi anziché proseguire.
Termini correlati
Domande frequenti
Serve un software particolare per risolvere un identificatore did:web?
No. L'identificatore è una ricetta per costruire un URL, e recuperare quell'URL via HTTPS restituisce il documento. Qualsiasi client HTTP può farlo, ed è il motivo per cui did:web è di solito il primo metodo che un team mette in funzione. In produzione conviene comunque usare una libreria di risoluzione generica, perché applica in modo uniforme le regole di codifica e i controlli sul documento invece di lasciarli a ogni chiamante.
did:web è meno affidabile perché non c'è una blockchain?
È affidabile in modo diverso. Un metodo basato su un registro distribuito ripartisce la registrazione tra molte parti, così che nessuna possa riscriverla in silenzio. did:web affida quella responsabilità al titolare del dominio e alle autorità di certificazione dietro il suo TLS. Per un'organizzazione il cui nome e sito sono già ciò che i clienti riconoscono, quello è spesso il posto più onesto in cui far risiedere la fiducia, purché sia chiaro a tutti che il dominio è il punto debole.
Che fine fanno i credential già emessi quando le chiavi cambiano?
Un verificatore recupera il documento così com'è adesso, quindi un credential firmato con una chiave nel frattempo rimossa non si verifica più. Tenete nel documento una chiave dismessa, contrassegnata in modo che possa verificare ma non più firmare, almeno finché restano validi i credential che ha firmato. Se serve che un verificatore possa dimostrare quale chiave era in vigore a una certa data, è il punto in cui did:webvh vale la sua complessità aggiuntiva.
Fonti
Questa pagina è informativa e non costituisce consulenza legale. Per indicazioni autorevoli consultate direttamente le specifiche del W3C.