Si algo se atasca durante la implementación —una credencial que no verifica, un dispositivo que no firma, un flujo que no cierra— conviene saber de antemano por dónde escribir y cuánto puede tardar la respuesta. Aquí está el detalle real, sin promesas de atención instantánea.
Tiempos de respuesta habituales. Incidencias que bloquean un entorno en producción: mismo día hábil. Consultas de configuración o dudas de integración: entre uno y dos días hábiles. Solicitudes de revisión de alcance o cambios de planificación: se agendan dentro de la semana.
Antes de escribir, revisa la sección de recursos: buena parte de las dudas sobre credenciales, carteras y verificadores locales ya está documentada ahí.
¿Prefieres resolver primero las dudas frecuentes? El FAQ cubre los casos que más se repiten durante la puesta en marcha.
Ir al FAQ y preguntas frecuentesEn la implementación de Identia SSI, el verificador no es un servicio externo que recibe tus datos: es un componente local que confirma atributos concretos y emite pruebas. Estas son las ventajas que notan quienes adoptan el modelo en etapas tempranas.
La captura y comparación biométrica se ejecuta en el hardware del usuario. Lo que se transmite al verificador es una prueba criptográfica sobre un atributo, no la imagen ni la plantilla. El resultado: menos superficie de exposición en cada intercambio.
Para acreditar mayoría de edad o residencia no hace falta entregar el documento entero. Se presenta únicamente el atributo requerido, con la firma del emisor correspondiente. Reduce datos que circulan entre organizaciones y simplifica el cumplimiento.
La cartera digital vive bajo control del titular. Puede decidir qué credencial presenta en cada trámite y revocar el vínculo con un verificador cuando lo necesita. La pérdida del dispositivo se gestiona con recuperación, no con reemisión centralizada.
El validador local puede confirmar atributos en entornos con conectividad intermitente, como ventanillas de atención o accesos físicos. La sincronización con el registro del emisor se resuelve después, sin bloquear la operación.
Cada presentación deja un registro verificable de que el atributo fue comprobado, sin conservar el dato original. Las organizaciones auditan cumplimiento sin acumular perfiles biométricos de sus usuarios.
El modelo convive con sistemas de identidad existentes. Se incorpora primero en un caso acotado, se mide fricción real y se amplía según resultados. No exige apagar lo que ya funciona para empezar a operar.
Para ver el orden de etapas y las dependencias técnicas, revisa los recursos de implementación. Si necesitas coordinar un caso concreto, escríbenos desde contacto.
El despliegue de identidad autosoberana no ocurre de golpe. Cada fase resuelve una pieza concreta: emisión de credenciales, validación local, interoperabilidad entre organismos y soporte al usuario cuando algo falla. Estas son las etapas que seguimos en proyectos reales, con lo que se espera de cada una y las limitaciones que conviene tener presentes antes de empezar.
Antes de tocar infraestructura, se acota qué atributo se va a verificar: mayoría de edad, residencia, titulación o pertenencia a un colectivo. El alcance define qué credencial se emite y qué se descarta. Si el atributo no está bien delimitado, el verificador local no puede reducir nada y el proceso termina exponiendo más datos de los necesarios.
El emisor firma la credencial y la deposita en la cartera del usuario. En esta etapa se decide el formato, la vigencia y las condiciones de revocación. Un error común es emitir credenciales con campos de más: cada dato añadido amplía la superficie de exposición y complica la revocación selectiva más adelante.
El verificador local comprueba que quien presenta la credencial es su titular. La plantilla biométrica no sale del dispositivo; solo se emite una prueba criptográfica sobre el atributo. En hardware limitado, esta fase exige ajustar umbrales de tolerancia y prever el caso de dispositivos sin sensor compatible.
El servicio que recibe la prueba comprueba la firma del emisor y la vigencia de la credencial, sin acceder a los datos originales. Aquí aparecen los problemas de interoperabilidad: formatos distintos, listas de revocación desincronizadas y registros que no aceptan pruebas selectivas. Es la fase donde más tiempo se consume en integración.
Toda credencial necesita un mecanismo de baja. Cuando el usuario pierde el teléfono o cambia de titularidad, la revocación debe propagarse sin dejar credenciales huérfanas. Este punto se diseña antes del lanzamiento, no después: recuperarlo a posteriori obliga a rehacer la lógica de emisión.
Una vez en uso, hacen falta registros de auditoría que permitan reconstruir qué prueba se presentó, cuándo y ante quién, sin conservar el dato sensible. También un canal de soporte para casos de verificación fallida. Sin esta capa, cualquier incidencia se convierte en una investigación manual sobre datos que ya no deberían existir.