ho pensato di più al caso NDI del bhutan e c'è un aspetto che non ho visto nessuno approfondire correttamente cosa significano effettivamente tre migrazioni della piattaforma per il lato dei verificatori della rete.
la maggior parte della copertura si concentra sull'esperienza dei cittadini. adozione del portafoglio. numeri di iscrizione. emissione di credenziali. e quel inquadramento ha senso perché 750.000 cittadini iscritti è il numero principale. ma la rete dei verificatori è dove si trova il vero costo della migrazione.
ecco la questione riguardo all'infrastruttura dell'identità specificamente è un sistema a due facce. hai gli emittenti da un lato, i verificatori dall'altro, e un registro di fiducia nel mezzo da cui entrambe le parti dipendono. quando una banca vuole confermare che una credenziale nel portafoglio di qualcuno è stata effettivamente emessa dal governo del bhutan, si sta risolvendo rispetto a quel registro di fiducia. quando un'agenzia governativa vuole verificare l'identità di qualcuno a un banco di servizio, la stessa cosa.
ogni integrazione sul lato del verificatore è costruita contro una catena specifica. un metodo DID specifico. una posizione del registro specifica. quando si migra da hyperledger indy a polygon, ognuna di quelle integrazioni deve essere ricostruita. i DID degli emittenti devono essere riancorati e risolvibili sulla nuova catena. i registri di revoca devono migrare in modo pulito. il software del verificatore deve essere aggiornato per risolvere contro il nuovo registro.
fai questo una volta ed è doloroso ma sopportabile. fallo due volte in due anni su un sistema nazionale attivo e inizi a chiederti come appare il tasso di abbandono dei verificatori. quante integrazioni sono state completamente ricostruite rispetto a quelle abbandonate silenziosamente. quanti fornitori di servizi stanno ancora risolvendo contro il vecchio registro indy e stanno ottenendo errori silenziosi che non hanno ancora diagnosticato.
lo strato degli standard W3C dovrebbe isolare contro esattamente questo; se tutti si conformano allo stesso formato di credenziali e specifica DID, la migrazione dovrebbe essere per lo più un esercizio di riancoraggio del registro piuttosto che una ricostruzione completa. ma la conformità agli standard è un pavimento, non un soffitto. il divario tra conforme alla specifica e operativamente senza soluzione di continuità è dove vivono i sistemi reali e dove si accumulano i costi di migrazione reali.
@SignOfficial sta scommettendo su un'architettura specifica che puoi costruire un'infrastruttura di identità sovrana abbastanza stabile a livello di protocollo da non far sì che i governi finiscano per passare attraverso questo. il contesto del Medio Oriente rende quella scommessa particolarmente interessante perché queste sono economie con il capitale e la volontà politica di costruire correttamente fin dall'inizio, piuttosto che lanciarsi rapidamente e assorbire i costi di migrazione in seguito.
se la fondazione $SIGN che si sta posando regge effettivamente sotto quel tipo di pressione di distribuzione su scala sovrana, questo è ciò su cui sto ancora lavorando.