#dusk $DUSK
Estos días volví a mirar la Citadel 2 de @Dusk .
Antes siempre lo había entendido como una “herramienta de identidad ZK”. Ahora pienso que esa descripción es un poco demasiado simplista.
En realidad, no pretende tomar tantas decisiones en nombre de la plataforma.
El usuario primero pasa por la validación offline del License Provider y obtiene el credential. Luego, al acceder a algún servicio, usa una prueba ZK para demostrar que realmente tiene una credencial válida.
Hasta aquí, lo que Citadel puede demostrar es que esa credencial no presenta problemas.
Pero si la plataforma reconoce o no a ese LP, si el credential aún se puede usar, si ha sido revocado, si la sesión necesita o no una nueva validación… todo eso no lo gestiona Citadel automáticamente por ti.
Cuando empecé a mirar esta parte, me quedé un poco confundido, me parecía como si “solo se hubiera hecho la mitad”.
Después lo entendí: el negocio financiero, de por sí, no puede tener una única capa de reglas de acceso.
Que una misma credencial se pueda usar o no, en regiones distintas, con productos distintos y en plataformas distintas, es otra cuestión.
Así que, ahora, más bien siento que el diseño de Citadel 2 es bastante contenido.
Primero se encarga de que “esta prueba sea auténtica”; en cuanto a “si esta prueba es suficiente”, lo deja para que el negocio en concreto lo decida.
Incluso cosas como revocation, expiration y session replay tampoco vienen empaquetadas como si el protocolo ya lo resolviera todo por ti.
Este punto me importa.
Porque muchos proyectos, cuando se topan con ZK, tienden con facilidad a cargar todo tipo de problemas sobre la idea de que “la criptografía puede resolverlo”.
Con Citadel 2, por ahora, no me da esa sensación.
Se parece más a: primero deja bien hecha la capa de prueba de credenciales y, en la parte de las reglas posteriores, que cada quien se haga cargo de lo que le corresponde.
Estos días volví a mirar la Citadel 2 de @Dusk .
Antes siempre lo había entendido como una “herramienta de identidad ZK”. Ahora pienso que esa descripción es un poco demasiado simplista.
En realidad, no pretende tomar tantas decisiones en nombre de la plataforma.
El usuario primero pasa por la validación offline del License Provider y obtiene el credential. Luego, al acceder a algún servicio, usa una prueba ZK para demostrar que realmente tiene una credencial válida.
Hasta aquí, lo que Citadel puede demostrar es que esa credencial no presenta problemas.
Pero si la plataforma reconoce o no a ese LP, si el credential aún se puede usar, si ha sido revocado, si la sesión necesita o no una nueva validación… todo eso no lo gestiona Citadel automáticamente por ti.
Cuando empecé a mirar esta parte, me quedé un poco confundido, me parecía como si “solo se hubiera hecho la mitad”.
Después lo entendí: el negocio financiero, de por sí, no puede tener una única capa de reglas de acceso.
Que una misma credencial se pueda usar o no, en regiones distintas, con productos distintos y en plataformas distintas, es otra cuestión.
Así que, ahora, más bien siento que el diseño de Citadel 2 es bastante contenido.
Primero se encarga de que “esta prueba sea auténtica”; en cuanto a “si esta prueba es suficiente”, lo deja para que el negocio en concreto lo decida.
Incluso cosas como revocation, expiration y session replay tampoco vienen empaquetadas como si el protocolo ya lo resolviera todo por ti.
Este punto me importa.
Porque muchos proyectos, cuando se topan con ZK, tienden con facilidad a cargar todo tipo de problemas sobre la idea de que “la criptografía puede resolverlo”.
Con Citadel 2, por ahora, no me da esa sensación.
Se parece más a: primero deja bien hecha la capa de prueba de credenciales y, en la parte de las reglas posteriores, que cada quien se haga cargo de lo que le corresponde.