he estado pensando que estaba equivocado sobre tantas cosas como los gráficos de RIVER y PIPPIN y la infraestructura de confianza equivocada durante la mayor parte de este año y, sinceramente, me llevó un mecánico específico a mostrarme dónde se rompió mi modelo mental 😂
seguí pensando en credenciales verificables de la manera en que la mayoría de la gente lo hace - como un reemplazo para documentos en papel. más limpios, más difíciles de falsificar, portátiles a través de fronteras. y ese marco es correcto hasta donde llega. pero pasé los últimos dos días profundamente en la capa de revocación de la pila de identidad SIGN y algo sobre eso me sigue atrayendo. porque la revocación es donde el diseño se vuelve genuinamente difícil. y donde se complica no es donde lo esperaba.
Lo que construyeron aquí:
el marco de identidad SIGN implementa la revocación de credenciales a través del estándar de Lista de Estado de Bitstrings del W3C. esto es lo que realmente significa mecánicamente.
cuando una agencia gubernamental emite un credential, una licencia profesional, una certificación de título de propiedad, una prueba de elegibilidad, ese credential contiene un puntero. una referencia a una posición específica en un bitstring publicado. el bitstring es una larga secuencia de bits, cada uno mapeado a un credential emitido específico. cuando el credential es válido, su bit se establece en cero. cuando el emisor lo revoca, licencia expirada, documento fraudulento, elegibilidad cambiada, el bit cambia a uno.
los verificadores comprueban la validez del credential al obtener el bitstring y leer el bit en la posición a la que apunta el credential. si el bit es cero, el credential es válido. si es uno, está revocado. no hay necesidad de contactar a la autoridad emisora directamente. no hay llamada API de vuelta a la base de datos gubernamental. la verificación es autosuficiente y el emisor queda completamente fuera del bucle de verificación.
ese es un diseño genuinamente elegante. el emisor publica un bitstring que cubre miles de credenciales simultáneamente. los verificadores verifican el estado sin revelar al emisor que se está verificando un credential específico. el titular presenta su credential sin que el emisor sepa dónde o cuándo se está utilizando. la privacidad se preserva en la unión emisor-verificador por diseño.
Dónde me quedé atascado:
el problema no es con el bitstring en sí. el problema es con quién lo aloja y qué revela su búsqueda.
cuando un verificador obtiene el bitstring para verificar el estado de un credential, esa solicitud de búsqueda va a algún lugar. llega a un servidor. y ese servidor, quien sea que aloje el bitstring publicado, puede ver la solicitud. puede ver la dirección IP del verificador, la marca de tiempo, y al correlacionar con el puntero del credential, potencialmente inferir qué credential se está verificando y en qué contexto.
la especificación del W3C reconoce esto. señala que el servidor anfitrión aprende algo de los patrones de búsqueda incluso si el bitstring en sí es preservador de la privacidad. la mitigación recomendada es el almacenamiento en caché. los verificadores descargan y almacenan en caché el bitstring completo en lugar de obtenerlo por cada verificación, de modo que las verificaciones individuales se vuelven invisibles para el anfitrión.
la documentación de SIGN implementa el estándar del W3C pero no especifica requisitos de caché, ventanas de frescura de caché, o qué ocurre cuando un credential es revocado pero un verificador está operando desde un bitstring almacenado en caché obsoleto.
Mi preocupación con esto:
esa última parte es la que no puedo resolver. la frescura de la caché es un intercambio directo entre la privacidad y la velocidad de revocación. un verificador que almacena en caché el bitstring durante 24 horas protege la privacidad. su patrón de búsqueda no revela nada sobre verificaciones individuales durante ese tiempo. pero también significa que un credential revocado a las 9am todavía se muestra como válido para cualquier verificador que opere en una caché de la noche anterior.
para una licencia profesional esto probablemente sea aceptable. para un credential utilizado para autorizar una transacción de alto valor o un cruce fronterizo, un retraso de revocación de 24 horas es una verdadera brecha operativa. y para que la infraestructura funcione correctamente, cada verificador en cada agencia a través de un despliegue soberano necesita operar con una política de caché que el protocolo en sí no define.
el diseño es correcto
el estándar es correcto
lo que no se especifica es la gobernanza de la caché. quién establece la ventana de frescura, cuál es el tiempo mínimo aceptable de propagación de revocación, y qué ocurre en la capa de verificación cuando un credential revocado aún no ha surgido en una caché obsoleta.
honestamente no sé si el modelo de revocación de bitstrings es lo suficientemente limpio como para que la gobernanza de caché sea solo un detalle de implementación que cada despliegue resuelve, o si la brecha entre la revocación y la propagación es el tipo de cosa que surge mal en un sistema soberano en vivo cuando más importa?? 🤔
#SignDigitalSovereignInfra @SignOfficial $SIGN
