#dusk $DUSK @Dusk ¿Con un servicio de pruebas de conocimiento cero hay que meterte sí o sí ahí? Al leer la documentación de Citadel 2 de @Dusk , descubrí que la respuesta es, de hecho, no. El contrato de Citadel solo se encarga de verificar que la sesión es criptográficamente válida; el verdadero criterio para permitir o no el acceso sigue siendo el Service Provider. Este límite se puede pasar fácilmente por alto con una frase como “no hace falta revelar información personal”: el usuario obtiene primero las credenciales del License Provider y luego genera la prueba, demostrando que posee una licencia registrada y emitida por una institución confiable. En la cadena no se ve qué documento usa. Pero cuando llega al punto de acceso, el SP aún tiene que decidir por sí mismo a qué LP confía y qué atributos acepta; también debe comprobar si la sesión ha caducado o fue revocada, y si las cookies pueden reutilizarse.
Creo que ahí Citadel 2 es más honesto: no envuelve “la prueba es válida” como “la autorización se aprueba automáticamente”, sino que separa la verificación criptográfica de la autorización del negocio en dos pasos. Para el usuario se expone menos información personal; para la parte del servicio, las reglas no desaparecen, solo pasan de recolectar un conjunto completo de datos a elegir fuentes de confianza y revisar el estado de la sesión. El escenario de presión también es muy concreto: la prueba del usuario es completamente correcta, pero el servicio lo rechaza porque no confía en el LP que emitió esa licencia o porque detecta que la sesión ya expiró. Entonces el usuario puede pensar que la cadena falló, pero el SP considerará que simplemente está ejecutando su política. Si la página solo muestra “falló la verificación”, ambas partes no encuentran el verdadero punto de responsabilidad.
Así que, al observar el diseño de identidad de DUSK ahora, no me limitaré a preguntarme cuánto puede ocultar de atributos; también quiero ver si cada aplicación explica con claridad la diferencia entre “la prueba es válida” y “el servicio concede el acceso”. La Citadel 2 de @Dusk efectivamente puede reducir la divulgación innecesaria de información, pero no puede decidir por la aplicación a quién confiar. Lo más interesante por observar en el futuro es si, cuando se rechaza, el usuario puede saber exactamente si el problema está en la prueba, en las credenciales o en la política del servicio. #dusk
Creo que ahí Citadel 2 es más honesto: no envuelve “la prueba es válida” como “la autorización se aprueba automáticamente”, sino que separa la verificación criptográfica de la autorización del negocio en dos pasos. Para el usuario se expone menos información personal; para la parte del servicio, las reglas no desaparecen, solo pasan de recolectar un conjunto completo de datos a elegir fuentes de confianza y revisar el estado de la sesión. El escenario de presión también es muy concreto: la prueba del usuario es completamente correcta, pero el servicio lo rechaza porque no confía en el LP que emitió esa licencia o porque detecta que la sesión ya expiró. Entonces el usuario puede pensar que la cadena falló, pero el SP considerará que simplemente está ejecutando su política. Si la página solo muestra “falló la verificación”, ambas partes no encuentran el verdadero punto de responsabilidad.
Así que, al observar el diseño de identidad de DUSK ahora, no me limitaré a preguntarme cuánto puede ocultar de atributos; también quiero ver si cada aplicación explica con claridad la diferencia entre “la prueba es válida” y “el servicio concede el acceso”. La Citadel 2 de @Dusk efectivamente puede reducir la divulgación innecesaria de información, pero no puede decidir por la aplicación a quién confiar. Lo más interesante por observar en el futuro es si, cuando se rechaza, el usuario puede saber exactamente si el problema está en la prueba, en las credenciales o en la política del servicio. #dusk
