Fui a buscar la Ciudadela esperando el documento de identidad autosoberana de la versión anterior y descubrí que en realidad se ha reconstruido en la Ciudadela 2.
El flujo es el siguiente: un usuario solicita a un proveedor de licencias una credencial. El proveedor los verifica fuera de la cadena y firma los atributos relevantes; luego registra una licencia cifrada en un contrato de Ciudadela. Más tarde, cuando el usuario quiere acceder a un servicio, genera una prueba de conocimiento cero que muestra que posee una licencia registrada válida sin revelar cuál es.
El contrato verifica eso y registra una sesión pública, y el usuario le entrega una cookie de sesión al proveedor del servicio.
Seis cosas específicas nunca tocan la cadena: la clave de la wallet, cuál licencia se usó, la clave del LP, la clave del SP, los atributos firmados y la ruta de prueba de Merkle.....
Lo interesante es que Ciudadela solo prueba que la sesión es criptográficamente válida; no decide políticas. Los documentos son explícitos en que el SP decide qué proveedores de licencias confiar y si una sesión está vencida o.
revocada; esa autoridad reside por completo en el SP.
Lo que los documentos no explican es cómo un SP podría apuntar a una licencia específica comprometida para su revocación, dado que la sesión misma nunca revela cuál
licencia la respaldó en primer lugar...
Si fueras un SP, ¿construirías la revocación alrededor de los IDs de sesión en lugar de la identidad de la licencia, dado que la licencia nunca se muestra realmente??
#dusk @Dusk $DUSK
El flujo es el siguiente: un usuario solicita a un proveedor de licencias una credencial. El proveedor los verifica fuera de la cadena y firma los atributos relevantes; luego registra una licencia cifrada en un contrato de Ciudadela. Más tarde, cuando el usuario quiere acceder a un servicio, genera una prueba de conocimiento cero que muestra que posee una licencia registrada válida sin revelar cuál es.
El contrato verifica eso y registra una sesión pública, y el usuario le entrega una cookie de sesión al proveedor del servicio.
Seis cosas específicas nunca tocan la cadena: la clave de la wallet, cuál licencia se usó, la clave del LP, la clave del SP, los atributos firmados y la ruta de prueba de Merkle.....
Lo interesante es que Ciudadela solo prueba que la sesión es criptográficamente válida; no decide políticas. Los documentos son explícitos en que el SP decide qué proveedores de licencias confiar y si una sesión está vencida o.
revocada; esa autoridad reside por completo en el SP.
Lo que los documentos no explican es cómo un SP podría apuntar a una licencia específica comprometida para su revocación, dado que la sesión misma nunca revela cuál
licencia la respaldó en primer lugar...
Si fueras un SP, ¿construirías la revocación alrededor de los IDs de sesión en lugar de la identidad de la licencia, dado que la licencia nunca se muestra realmente??
#dusk @Dusk $DUSK
