Integración de Wallet y titular

Una Wallet o servicio del titular es el límite de confianza orientado a la persona para recibir, proteger, comprender y presentar credenciales. Debe respaldar el control individual sin trasladar toda la carga de seguridad y recuperación a la persona.

Responsabilidades de la Wallet

Una integración conforme debe proporcionar controles claros para:

• recibir credenciales desde flujos de emisión reconocidos;
• mostrar emisor, tipo, validez y estado;
• proteger la credencial y el material de claves del titular;
• revisar solicitudes antes de presentar;
• seleccionar únicamente los claims necesarios;
• crear presentaciones recientes y vinculadas a la audiencia;
• administrar dispositivos y sesiones;
• admitir backup, continuidad y recuperación protegida;
• exportar o migrar credenciales admitidas cuando la política lo permita;
• comunicar de forma comprensible fallas y cambios de ciclo de vida.

La Wallet no debe divulgar silenciosamente credenciales no relacionadas, inventarios completos ni identificadores estables entre partes usuarias distintas.

Recepción de credenciales

Durante la emisión, la Wallet debe validar suficiente contexto para proteger al titular:

1. identificar emisor y credencial ofrecida;
2. confirmar que la transacción está vigente y destinada a esa interacción;
3. mostrar condiciones materiales y acción solicitada;
4. demostrar control de la clave requerida sin exponer material privado;
5. recibir y validar el formato;
6. guardar la credencial en el contenedor protegido aprobado;
7. confirmar el resultado de entrega sin revelar estado no relacionado de la Wallet.

La Wallet puede comprobar consistencia técnica, pero no reemplaza la responsabilidad del emisor por la verdad de los claims ni la política posterior del verificador.

Custodia protegida

La seguridad de la Wallet debe distinguir:

• payloads de credenciales;
• claves del titular y material de binding;
• estado de sesión de la aplicación;
• estado de registro de dispositivos;
• material de recuperación;
• índices y metadatos visibles para el usuario;
• backups y estado cifrado sincronizado.

Estos elementos pueden requerir controles distintos de protección, retención, migración y eliminación. La documentación pública describe el modelo, no el formato exacto del envelope de almacenamiento, parámetros de derivación, recovery shares ni secretos de dispositivos.

Autorización del titular y revisión de la presentación

Antes de presentar, el titular debe poder comprender:

• qué organización solicita evidencia;
• la finalidad declarada;
• qué credencial o tipo de evidencia es aceptable;
• qué claims se divulgarán;
• si se necesita una nueva prueba del titular;
• cuánto tiempo es válida la solicitud;
• si la parte usuaria conservará un comprobante;
• cómo cancelar o rechazar.

La autorización debe ser específica de la transacción. Una presentación anterior no debe convertirse en permiso permanente para solicitudes futuras no relacionadas.

Creación de la presentación

El flujo debe:

1. autenticar solicitud y contexto de la parte usuaria;
2. comparar la solicitud con credenciales compatibles;
3. aplicar política de Wallet y titular;
4. obtener autorización informada;
5. crear únicamente las disclosures requeridas;
6. vincular la respuesta con audiencia, nonce, transacción y tiempo;
7. añadir prueba del titular cuando el perfil lo requiera;
8. transmitir por un canal protegido aprobado;
9. mostrar un resultado claro al titular.

La Wallet no decide si la parte usuaria concede finalmente acceso, elegibilidad, onboarding u otro resultado institucional.

Ciclo de vida de dispositivos

La continuidad multidispositivo necesita estados explícitos. La integración puede admitir:

• enrolamiento de un dispositivo nuevo aprobado;
• verificación step-up para registros sensibles;
• visibilidad de dispositivos registrados;
• revocación de dispositivos perdidos o comprometidos;
• transferencia o sincronización de estado cifrado;
• separación entre dispositivos activos, pendientes, suspendidos y retirados;
• evidencia de eventos del ciclo de vida.

Un dispositivo nuevo no debe recibir automáticamente toda credencial o capacidad de recuperación solo porque el usuario se autenticó una vez.

Autenticación y sesiones

El acceso a la Wallet puede utilizar passkeys, biometría aprobada, device binding u otros métodos controlados por política. La autenticación establece acceso a la sesión; no demuestra que toda credencial sea válida ni autoriza toda presentación.

Las operaciones de alto impacto pueden exigir step-up, presencia reciente o aprobación adicional. Los métodos de fallback deben estar acotados, ser breves y más restringidos que el acceso ordinario.

Backup, continuidad y recuperación

El control del titular no es práctico si la pérdida de un dispositivo provoca exclusión permanente. La continuidad debe diseñarse antes del lanzamiento.

Una recuperación protegida debe separar:

• solicitud e inicio;
• assurance de identidad y dispositivo;
• autorización;
• preparación de material protegido;
• liberación por threshold o custodios;
• restauración a un dispositivo aprobado;
• rotación inmediata e invalidación del acceso previo;
• evidencia y notificación al usuario.

Ninguna aplicación, operador de soporte o custodio debe poseer un secreto universal de recuperación.

Portabilidad e interoperabilidad

Una Wallet debe admitir estándares y perfiles aprobados para evitar que las credenciales queden confinadas a una aplicación propietaria. La portabilidad sigue sujeta al formato, política del emisor, holder binding, estado y capacidades de la Wallet receptora.

La exportación no debe exponer llaves privadas ni eludir reglas de assurance. La migración puede exigir re-binding, reemisión o transferencia controlada, no una copia bruta de archivos.

Accesibilidad y control informado

El control del titular exige opciones utilizables. Los flujos deben considerar:

• lenguaje claro y no técnico;
• presentación multilingüe cuando corresponda;
• rutas accesibles de autorización y recuperación;
• alternativas cuando la biometría no sea apropiada;
• manejo seguro de flujos interrumpidos o abandonados;
• mensajes de estado y error comprensibles;
• soporte que no eluda la política de seguridad.

Checklist de readiness de la Wallet

Antes de producción, confirmar que:

• perfiles de recepción y presentación están fijados;
• el material privado permanece bajo protección aprobada del titular;
• se aplican autenticidad de solicitud y binding transaccional;
• el titular puede inspeccionar y limitar disclosures;
• enrolamiento y revocación de dispositivos son operacionales;
• la recuperación restaura control sin secreto universal de administrador;
• la portabilidad está documentada con precisión;
• se consideraron accesibilidad y alternativas no biométricas;
• superan pruebas de pérdida, replay, sesión comprometida y recuperación fallida;
• soporte no puede omitir autorización ni protección de claves.

Límite de la documentación pública

Esta página no publica formatos de envelopes, parámetros de derivación, secretos de dispositivos, distribución de recovery shares, topología de sincronización, umbrales biométricos, tokens de sesión ni configuración productiva de Wallet.

Consulta UbID Wallet, Autenticación y seguridad de dispositivos y Recuperación y continuidad.