m-am gândit mai mult la cazul NDI din Bhutan și există un unghi pe care nu am văzut pe nimeni să se aprofundeze corect, ce înseamnă de fapt migrarea a trei platforme pentru partea de verificatori a rețelei.
majoritatea acoperirii se concentrează pe experiența cetățeanului. adoptarea portofelului. numerele de înscriere. emiterea credentialelor. și această structurare are sens deoarece 750.000 de cetățeni înscriși este numărul principal. dar rețeaua de verificatori este locul unde se află adevăratul cost al migrației.
iată ce este cu infrastructura de identitate specific, este un sistem bilaterale. ai emitenți pe o parte, verificatori pe cealaltă, și un registru de încredere în mijloc pe care ambele părți se bazează. atunci când o bancă vrea să confirme că un credential din portofelul cuiva a fost într-adevăr emis de guvernul Bhutan, se rezolvă împotriva acelui registru de încredere. când o agenție guvernamentală vrea să verifice identitatea cuiva la un ghișeu de servicii, același lucru.
fiecare integrare pe partea de verificator este construită împotriva unui lanț specific. o metodă DID specifică. o locație a registrului specifică. când migrezi de la hyperledger indy la polygon, fiecare dintre aceste integrări trebuie să fie reconstruită. DIDs emitentului trebuie să fie re-ancorate și rezolvabile pe noul lanț. registrele de revocare trebuie să migreze curat. software-ul de verificare trebuie să fie actualizat pentru a rezolva împotriva noului registru.
fă asta o dată și e dureros, dar supraviețuibil. fă-o de două ori în doi ani pe un sistem național activ și începi să te întrebi cum arată rata de abandon a verificatorilor. câte integrări au fost reconstruite complet versus abandonate în tăcere. câți furnizori de servicii încă rezolvă împotriva vechiului registru indy și primesc eșecuri silențioase pe care nu le-au diagnosticat încă.
stratul standardelor W3C ar trebui să izoleze împotriva exact acest lucru; dacă toată lumea se conformează aceluiași format de acreditive și specificație DID, migrarea ar trebui să fie în mare parte un exercițiu de re-ancorare a registrului, mai degrabă decât o reconstruire completă. dar conformitatea cu standardele este un minim, nu un maxim. diferența dintre conformitatea specificației și funcționarea fără probleme este locul unde trăiesc sistemele reale și unde se acumulează costurile reale de migrare.
@SignOfficial face o pariu arhitectural specific că poți construi o infrastructură de identitate suverană suficient de stabilă la nivelul protocolului încât guvernele să nu ajungă să treacă prin asta. contextul din Orientul Mijlociu face ca acest pariu să fie deosebit de interesant deoarece acestea sunt economii cu capital și voință politică de a construi corect de la început, mai degrabă decât să lanseze rapid și să absoarbă costurile de migrare mai târziu.
dacă fundația $SIGN care se pune de fapt rezistă sub acea kind de presiune de desfășurare la scară suverană, asta este lucrul la care încă lucrez.