Cuando leí Citadel 2 me quedé detenido ante una frase. No es larga: los smart contracts solo se encargan de verificar la validez criptográfica de la sesión; si te dejo entrar o no, la decisión está en manos del Service Provider. 🤔
El usuario, tras mil apuros, genera una prueba válida… y la historia ni siquiera ha terminado; incluso, se podría decir, apenas empieza.
Puedes demostrar que posees una licencia válida emitida por algún License Provider. La información no necesita subirse a la cadena, y la privacidad queda protegida a conciencia. Pero el proveedor del servicio tiene un montón de cosas que debe decidir por sí mismo: ¿confío en este LP? ¿Qué atributos acepto? ¿La sesión ha expirado? ¿Fue revocada? ¿Esa cookie aún se puede usar una segunda vez?
La privacidad está protegida; la política del negocio no va a decidir por ti.
¿Cómo se ve el peor escenario?
El usuario genera la proof con éxito y la página muestra un mensaje emergente: «Acceso no autorizado».
Solo cuatro palabras. Y ya. 🥶
Entonces el usuario empieza a adivinar: ¿la prueba se volvió inválida? ¿el servicio no confía en el emisor? ¿o los atributos no cumplen con las reglas? Adivinan una ronda tras otra y no hay ninguna pista.
La privacidad, en efecto, no se filtra, pero el tiempo se consume en resolver el acertijo. Para el usuario, la privacidad se mantiene… pero la experiencia se cae.
Para el proveedor del servicio, todas las negativas se esconden tras un solo código de error; ni siquiera se puede explicar con claridad hasta dónde llegan los límites de cumplimiento.
Esa contención, en realidad, es lucidez.
El valor de Citadel 2 está aquí: prueba que tienes credenciales válidas, pero nunca finge que «tú debes» recibir el servicio.
La prueba es tuya; la decisión es del proveedor. Dos cosas que se mantienen bien separadas.
$DUSK La comunidad quiere usar esto para onboarding real, y @Dusk debería impulsar que la aplicación informe al usuario por separado si la proof es válida y si la política fue rechazada.
¿La prueba no pasó? ¿O la prueba sí pasó, pero la política lo rechazó? Meterlo en un solo código de error es más fácil; separarlo en dos es respetar la capacidad de juicio del usuario.
El usuario sabe en qué capa se atasca: y la experiencia de privacidad de #dusk solo está completa si ocurre así.
Si no, por muy buena que sea la protección de la privacidad, el usuario solo se queda con esas cuatro palabras. 🤷♂️
El usuario, tras mil apuros, genera una prueba válida… y la historia ni siquiera ha terminado; incluso, se podría decir, apenas empieza.
Puedes demostrar que posees una licencia válida emitida por algún License Provider. La información no necesita subirse a la cadena, y la privacidad queda protegida a conciencia. Pero el proveedor del servicio tiene un montón de cosas que debe decidir por sí mismo: ¿confío en este LP? ¿Qué atributos acepto? ¿La sesión ha expirado? ¿Fue revocada? ¿Esa cookie aún se puede usar una segunda vez?
La privacidad está protegida; la política del negocio no va a decidir por ti.
¿Cómo se ve el peor escenario?
El usuario genera la proof con éxito y la página muestra un mensaje emergente: «Acceso no autorizado».
Solo cuatro palabras. Y ya. 🥶
Entonces el usuario empieza a adivinar: ¿la prueba se volvió inválida? ¿el servicio no confía en el emisor? ¿o los atributos no cumplen con las reglas? Adivinan una ronda tras otra y no hay ninguna pista.
La privacidad, en efecto, no se filtra, pero el tiempo se consume en resolver el acertijo. Para el usuario, la privacidad se mantiene… pero la experiencia se cae.
Para el proveedor del servicio, todas las negativas se esconden tras un solo código de error; ni siquiera se puede explicar con claridad hasta dónde llegan los límites de cumplimiento.
Esa contención, en realidad, es lucidez.
El valor de Citadel 2 está aquí: prueba que tienes credenciales válidas, pero nunca finge que «tú debes» recibir el servicio.
La prueba es tuya; la decisión es del proveedor. Dos cosas que se mantienen bien separadas.
$DUSK La comunidad quiere usar esto para onboarding real, y @Dusk debería impulsar que la aplicación informe al usuario por separado si la proof es válida y si la política fue rechazada.
¿La prueba no pasó? ¿O la prueba sí pasó, pero la política lo rechazó? Meterlo en un solo código de error es más fácil; separarlo en dos es respetar la capacidad de juicio del usuario.
El usuario sabe en qué capa se atasca: y la experiencia de privacidad de #dusk solo está completa si ocurre así.
Si no, por muy buena que sea la protección de la privacidad, el usuario solo se queda con esas cuatro palabras. 🤷♂️
