Al ver el “hacer una sola KYC y poder reutilizarlo en todas partes” al usar Citadel 2 con $DUSK , me encantó ese punto. Le dediqué un poco de tiempo a calmarme y revisar la documentación y el repositorio de código, y recién entonces descubrí que aquí hay ciertas condiciones previas enterradas.
En términos simples, todo el proceso es así: el usuario realiza la verificación de identidad fuera de línea a través de un LP, obtiene un comprobante cifrado que se ancla en la cadena; luego, al acceder a cada aplicación, mediante pruebas ZK demuestra que cumple los requisitos, sin exponer información privada.
Al principio pensé que, con hacer una sola KYC y obtener el comprobante, ya podría reutilizarse en todas partes. Pero al seguir la lógica del protocolo de Citadel hacia adelante, encontré un detalle clave: el Service Provider tiene derecho a decidir por sí mismo en quién confía, es decir, qué License Provider acepta.
Citadel en sí no obliga a que todos los SP acepten el mismo estándar de credenciales. Por ejemplo, en el negocio A confían en el LP que eligieron; en el negocio B pueden no reconocerlo. Si haces la KYC en el negocio A y luego el negocio B no acepta el comprobante emitido por ese LP, tienes que hacer la KYC de nuevo. El alcance de la “reutilización de una sola KYC” queda, de forma natural, limitado a “un círculo pequeño” donde se reconocen mutuamente el mismo conjunto de LP. Si sales de ese círculo, la reutilización deja de funcionar $BTR
Quería ver qué tan bien estaba escrita la documentación de integración para instituciones. Revisé un poco y sí, el W3sper SDK existe, pero en cuanto a guías de integración a nivel institucional y soluciones de gestión de permisos, no encontré una versión suficientemente completa. Quizá busqué en el lugar equivocado, pero al menos en los canales públicos se ve que, si una institución quiere conectarse directamente, el umbral realmente no es bajo.
Comparemos con eIDAS en la Unión Europea: en el mundo real, la interoperabilidad de identidad ya se venía impulsando desde hace tiempo, solo que no se apoya en ZK. La idea técnica de Citadel está bien, pero el protocolo de identidad depende muchísimo del efecto de red. Para que el sistema funcione, tiene que haber muchos LP con licencia y que distintos SP de negocio estén dispuestos a aceptar esas credenciales. Intenté buscar ejemplos de LP externos con licencia ya implementados, pero después de revisar un poco no encontré información pública realmente clara. También puede ser que todavía esté en una fase temprana y que la información no esté extendida; pero al menos lo que se puede ver ahora es que el impulso principal todavía parece venir de #dusk , y la participación de terceros con licencia no es tan evidente.
No descarto conclusiones por ahora, pero seguiré de cerca dos señales clave: la implementación de LP con licencia externos y el lanzamiento oficial del JS SDK. Sin ver esos cambios, el “KYC reutilizable de por vida” todavía tiene un largo camino por recorrer @Dusk .
En términos simples, todo el proceso es así: el usuario realiza la verificación de identidad fuera de línea a través de un LP, obtiene un comprobante cifrado que se ancla en la cadena; luego, al acceder a cada aplicación, mediante pruebas ZK demuestra que cumple los requisitos, sin exponer información privada.
Al principio pensé que, con hacer una sola KYC y obtener el comprobante, ya podría reutilizarse en todas partes. Pero al seguir la lógica del protocolo de Citadel hacia adelante, encontré un detalle clave: el Service Provider tiene derecho a decidir por sí mismo en quién confía, es decir, qué License Provider acepta.
Citadel en sí no obliga a que todos los SP acepten el mismo estándar de credenciales. Por ejemplo, en el negocio A confían en el LP que eligieron; en el negocio B pueden no reconocerlo. Si haces la KYC en el negocio A y luego el negocio B no acepta el comprobante emitido por ese LP, tienes que hacer la KYC de nuevo. El alcance de la “reutilización de una sola KYC” queda, de forma natural, limitado a “un círculo pequeño” donde se reconocen mutuamente el mismo conjunto de LP. Si sales de ese círculo, la reutilización deja de funcionar $BTR
Quería ver qué tan bien estaba escrita la documentación de integración para instituciones. Revisé un poco y sí, el W3sper SDK existe, pero en cuanto a guías de integración a nivel institucional y soluciones de gestión de permisos, no encontré una versión suficientemente completa. Quizá busqué en el lugar equivocado, pero al menos en los canales públicos se ve que, si una institución quiere conectarse directamente, el umbral realmente no es bajo.
Comparemos con eIDAS en la Unión Europea: en el mundo real, la interoperabilidad de identidad ya se venía impulsando desde hace tiempo, solo que no se apoya en ZK. La idea técnica de Citadel está bien, pero el protocolo de identidad depende muchísimo del efecto de red. Para que el sistema funcione, tiene que haber muchos LP con licencia y que distintos SP de negocio estén dispuestos a aceptar esas credenciales. Intenté buscar ejemplos de LP externos con licencia ya implementados, pero después de revisar un poco no encontré información pública realmente clara. También puede ser que todavía esté en una fase temprana y que la información no esté extendida; pero al menos lo que se puede ver ahora es que el impulso principal todavía parece venir de #dusk , y la participación de terceros con licencia no es tan evidente.
No descarto conclusiones por ahora, pero seguiré de cerca dos señales clave: la implementación de LP con licencia externos y el lanzamiento oficial del JS SDK. Sin ver esos cambios, el “KYC reutilizable de por vida” todavía tiene un largo camino por recorrer @Dusk .