Los datos obsoletos son donde la mayoría de los sistemas de identidad mueren silenciosamente. No en la emisión. No en la pequeña demostración limpia donde alguien m-26 una credencial y un verificador asiente y todos pretenden que la confianza ha sido resuelta. Muere más tarde—cuando el estado cambia, cuando la credencial expira, cuando una revocación tiene que propagarse a través de sistemas que no se actualizan al mismo tiempo, y de repente la mitad de la pila piensa que la reclamación sigue siendo válida mientras que la otra mitad ya ha seguido adelante.
Ese es el verdadero problema con la charla sobre identidad estática. Asume que la verdad es una instantánea. No lo es. En producción, la verdad tiene un ciclo de vida, y en el segundo en que intentas mover credenciales a través de cadenas, aplicaciones, billeteras, instituciones y cualquier middleware medio roto que alguien envió hace seis meses, el problema deja de ser “¿está esto firmado?” y se convierte en “¿sigue siendo cierto en este momento?”. La mayoría de los equipos son terribles en esa parte. Se obsesionarán con las firmas, los esquemas, la jerga DID, todo el lenguaje del protocolo que se ve bien, luego empujarán el manejo del estado a algún servicio secundario y actuarán sorprendidos cuando todo se convierta en un infierno de API obsoleta.
La revocación es donde toda la fantasía colapsa. Porque ahora no estás verificando un objeto estático, estás resolviendo el estado en vivo bajo latencia, sincronización parcial, invalidación de caché, diferentes políticas de verificación, reglas específicas del emisor y todos los deliciosos pequeños casos extremos que surgen una vez que algo tiene que ser verificado fuera del propio entorno del emisor. Un sistema consulta cada minuto, otro cada hora, otro almacena en caché las respuestas porque el producto quería menor latencia, y ahora has construido una pesadilla de resolución de estado distribuido donde “válido” depende de quién preguntó, cuándo preguntó y qué ruta de lectura rota le tocó. [Y no, no me importa tu presentación sobre “identidad descentralizada” si la API está retrasada.]
Es un desastre.
Por eso la lógica del ciclo de vida de Sign es la primera parte que realmente se siente como si alguien hubiera sido quemado por la realidad antes. Lo interesante no es que puede emitir atestaciones. Muchos sistemas pueden escribir un registro y llamarlo infraestructura. Lo interesante es que Sign parece entender que las credenciales no son eventos únicos. Expiran. Son revocadas. Son reemplazadas. Son disputadas. Si tu modelo de verificación no trata esos como transiciones de estado de primera clase, no estás construyendo rieles de confianza, estás construyendo pudrición de la pista de auditoría con mejor marca.
Y aquí es donde el dolor operativo comienza a volverse costoso. Un sistema de concesión, flujo de control de acceso, motor de recompensas, registro de contribuyentes—lo que sea—realmente no le importa que un usuario alguna vez tuvo una credencial válida. Le importa si la reclamación es utilizable ahora. Esa es la parte que la gente pasa por alto. “Era cierto” no es lo mismo que “sigue siendo cierto”, y los sistemas distribuidos están llenos de pequeñas mentiras que aparecen en el vacío entre esos dos estados. Un verificador resuelve un estado fresco. Otro utiliza un estado en caché. Otro funciona fuera de línea por un tiempo y se sincroniza más tarde. Ahora tu supuesta capa de identidad determinista es solo lodo de hoja de cálculo con estética criptográfica.
He visto este patrón demasiadas veces. Alguien quiere credenciales reutilizables. Genial. Luego se dan cuenta de que las credenciales reutilizables también significan modos de falla reutilizables. Una mala actualización del emisor, una verificación de revocación obsoleta, un indexador rezagado, un servicio que optimiza la velocidad en lugar de la frescura, y de repente la misma credencial produce diferentes respuestas dependiendo de dónde se verifique. Eso no es un caso extremo raro. Ese es un comportamiento distribuido normal.
Por eso la identidad estática es un marco tan perezoso.
La parte difícil nunca fue la emisión. La parte difícil es el estado bajo cambio. Ciclos de vida. Propagación de revocación. Aplicación de caducidad. Consistencia entre sistemas. Toda la basura aburrida que nadie incluye en la presentación principal porque arruina la ilusión de que la confianza es limpia. No es limpia. Es principalmente fricción operativa más supuestos de tiempo más una desesperada esperanza de que nadie note la deriva del estado hasta después de que se publique la captura de pantalla del panel.
Firmar, al menos, parece que está apuntando a la herida correcta. Si la pila se toma en serio el ciclo de vida de las credenciales, entonces la verificación se convierte en menos en admirar firmas y más en sobrevivir a un estado cambiante sin perder la pista de auditoría. Esa es la única versión que importa.
Y si no diseñas problemas de caché desde el principio, la identidad distribuida se pudrirá desde la ruta de lectura mucho antes de que la criptografía falle.