El flujo de trabajo de Identia SSI no empieza en un servidor central. Empieza en el dispositivo del usuario, donde un verificador local comprueba atributos biométricos y emite pruebas criptográficas sin mover el dato original. Estas son las ventajas concretas que notan quienes ya operan con este modelo.
La captura y comparación biométrica ocurre en el hardware del usuario. Lo que viaja al verificador es una prueba sobre un atributo puntual, no la imagen ni la plantilla. Si el dispositivo se pierde, no hay una base central con rostros o huellas que filtrar.
Para confirmar mayoría de edad, residencia o vigencia de una credencial no hace falta entregar el documento entero. Se presenta solo el atributo que la otra parte necesita validar, y el resto permanece fuera de la transacción.
Cuando una credencial caduca o se revoca, el usuario recibe una nueva prueba firmada. No hay que volver a capturar biometría ni repetir el proceso completo desde cero, algo que en los sistemas centralizados suele implicar una nueva visita presencial.
El verificador local corre en teléfonos de gama media, pero la latencia y la calidad de la prueba dependen del sensor disponible. En dispositivos antiguos conviene planificar verificaciones asíncronas o complementar con un segundo factor.
Una credencial emitida por un organismo puede presentarse ante otro sin acuerdos bilaterales previos, siempre que ambos respeten el mismo formato de credenciales verificables. Esto reduce la integración técnica a un protocolo común, no a una API propietaria por cada contraparte.
Cada verificación deja un registro de que se comprobó un atributo en un momento dado, sin almacenar el valor del atributo. Los organismos pueden auditar el proceso sin acumular datos personales que después se conviertan en un riesgo.
Si querés ver cómo se combinan estos puntos en un caso real, podés revisar los recursos sobre credenciales verificables o escribirnos desde la página de contacto para plantear tu escenario.
El trabajo con credenciales verificables no se resuelve de una vez. Cada fase deja algo funcionando: primero el marco de identificadores, después la validación local, más tarde la interoperabilidad entre organizaciones. Estas son las etapas que ya recorrimos y las que están en curso, con lo que quedó cerrado y lo que sigue abierto.
Fijamos cómo se generan y resuelven los identificadores descentralizados dentro del portal. La decisión clave fue no depender de un registro único: cada credencial apunta a un documento que el usuario puede mover entre carteras sin perder validez. Quedó documentado el formato y los casos de rotación de claves.
El verificador local compara la plantilla biométrica contra el atributo declarado y emite una prueba, no la imagen ni el dato original. Probamos el flujo con hardware modesto y anotamos dónde falla: sensores antiguos, poca memoria disponible y ausencia de enclave seguro. Esas limitaciones están publicadas en la sección de recursos.
Corrimos tres escenarios acotados: verificación de mayoría de edad, acreditación de residencia y acceso a un servicio regulado. En cada uno medimos cuántos datos dejaban de circular respecto al proceso tradicional. El resultado fue dispar: el ahorro es claro en edad, mucho menor en residencia por requisitos legales de respaldo.
Etapa en curso. Estamos ajustando cómo dos organizaciones que no se conocen validan la misma credencial sin un intermediario central. El cuello de botella no es criptográfico sino de gobernanza: quién define los esquemas, quién revoca y cómo se notifica una revocación cuando el usuario está desconectado.
Pendiente de cierre. La pérdida del dispositivo es el punto más frágil del modelo. Trabajamos con listas de revocación compactas y con un mecanismo de recuperación que no reintroduzca un custodio central. Todavía no hay una solución que nos convenza del todo, y preferimos decirlo antes que publicar un flujo a medias.