ho pensato di aver sbagliato su così tante cose come i grafici di RIVER e PIPPIN e l'infrastruttura di fiducia sbagliata per la maggior parte di quest'anno e onestamente ci è voluto un meccanismo specifico per mostrarmi dove il mio modello mentale si è rotto 😂
continuavo a pensare ai credenziali verificabili come la maggior parte delle persone fa - come un sostituto dei documenti cartacei. più puliti, più difficili da falsificare, portabili oltre i confini. e quel inquadramento è corretto per quanto riguarda. ma ho passato gli ultimi due giorni a fondo nello strato di revoca dello stack di identità SIGN e qualcosa in merito continua a riportarmi indietro. perché la revoca è dove il design diventa genuinamente difficile. e dove diventa difficile non è dove mi aspettavo.
Cosa hanno costruito qui:
il framework di identità SIGN implementa la revoca delle credenziali attraverso lo standard W3C Bitstring Status List. ecco cosa significa effettivamente meccanicamente.
quando un'agenzia governativa emette una credenziale, una licenza professionale, un'attestazione di titolo di proprietà, una prova di idoneità, quella credenziale contiene un puntatore. un riferimento a una posizione specifica in una bitstring pubblicata. la bitstring è una lunga sequenza di bit, ciascuno mappato a una credenziale emessa specifica. quando la credenziale è valida, il suo bit è impostato su zero. quando l'emittente la revoca, licenza scaduta, documento fraudolento, cambiata idoneità, il bit passa a uno.
i verificatori controllano la validità della credenziale recuperando la bitstring e leggendo il bit nella posizione a cui punta la credenziale. se il bit è zero, la credenziale è valida. se è uno, è revocata. non è necessario contattare direttamente l'autorità emittente. nessuna chiamata API di ritorno al database governativo. il controllo è autonomo e l'emittente rimane completamente fuori dal ciclo di verifica.
quello è un design genuinamente elegante. l'emittente pubblica una bitstring che copre migliaia di credenziali simultaneamente. i verificatori controllano lo stato senza rivelare all'emittente che una specifica credenziale è in fase di verifica. il titolare presenta la propria credenziale senza che l'emittente sappia dove o quando viene utilizzata. la privacy è preservata al punto di incontro emittente-verificatore per design.
Dove mi sono bloccato:
il problema non è con la bitstring stessa. il problema è con chi la ospita e cosa rivela il suo recupero.
quando un verificatore recupera la bitstring per controllare lo stato di una credenziale, quella richiesta di recupero va da qualche parte. colpisce un server. e quel server, chiunque ospiti la bitstring pubblicata, può vedere la richiesta. può vedere l'indirizzo IP del verificatore, il timestamp e, correlando con il puntatore della credenziale, può potenzialmente inferire quale credenziale è in fase di controllo e in quale contesto.
la specifica W3C riconosce questo. nota che il server di hosting apprende qualcosa dai modelli di recupero anche se la bitstring stessa preserva la privacy. la mitigazione raccomandata è la memorizzazione nella cache. i verificatori scaricano e memorizzano nella cache l'intera bitstring piuttosto che recuperarla per ogni verifica, quindi i controlli individuali diventano invisibili all'host.
i documenti SIGN implementano lo standard W3C ma non specificano i requisiti di memorizzazione nella cache, le finestre di freschezza della cache o cosa succede quando una credenziale è revocata ma un verificatore opera da una bitstring memorizzata nella cache obsoleta.
La mia preoccupazione con questo:
quella parte finale è quella che non riesco a risolvere. la freschezza della cache è un compromesso diretto tra privacy e velocità di revoca. un verificatore che memorizza la bitstring per 24 ore protegge la privacy. il loro modello di recupero non rivela nulla sulle verifiche individuali durante quel periodo. ma ciò significa anche che una credenziale revocata alle 9 del mattino continua a mostrarsi valida per qualsiasi verificatore che opera su una cache della notte precedente.
per una licenza professionale questo è probabilmente accettabile. per una credenziale utilizzata per autorizzare una transazione di alto valore o un attraversamento di confine, un ritardo di revoca di 24 ore è una vera lacuna operativa. e affinché l'infrastruttura funzioni correttamente, ogni verificatore in ogni agenzia all'interno di una distribuzione sovrana deve operare su una politica di cache che il protocollo stesso non definisce.
il design è corretto
lo standard è corretto
ciò che non è specificato è la governance della cache. chi stabilisce la finestra di freschezza, qual è il tempo minimo accettabile per la propagazione della revoca e cosa succede a livello di verifica quando una credenziale revocata non è ancora emersa in una cache obsoleta.
onestamente non so se il modello di revoca della bitstring sia sufficientemente pulito da considerare la governance della cache solo un dettaglio di implementazione che ogni distribuzione risolve o se il divario tra revoca e propagazione sia il tipo di problema che emerge male in un sistema sovrano dal vivo quando conta di più?? 🤔
#SignDigitalSovereignInfra @SignOfficial $SIGN
