Modelo de integración

Una integración UbID es una relación gobernada entre participantes que intercambian evidencia verificable. El flujo técnico es solo una parte del modelo. Autoridad, finalidad, responsabilidad sobre datos, política de confianza, ciclo de vida y evidencia operacional deben definirse en conjunto.

Participantes y responsabilidades

Participante	Responsabilidad principal	No debe suponerse que
Emisor	Valida la base de los claims y emite credenciales gobernadas	Adopta la decisión final de la parte usuaria
Sujeto	Persona o entidad descrita por los claims	Siempre coincide con el titular
Titular	Controla la recepción y presentación de credenciales	Determina si un emisor es confiable para todos los verificadores
Wallet o servicio del titular	Protege credenciales, claves, autorización y contexto de presentación	Divulga silenciosamente credenciales o claims no relacionados
Verificador	Valida evidencia presentada y evalúa política de verificación	Trata una firma válida como derecho automático
Parte usuaria	Adopta la decisión institucional o de negocio final	Delega toda responsabilidad a la tecnología de credenciales
Proveedor de proofing	Produce evidencia o assurance utilizado por un emisor o política	Se convierte en emisor solo por suministrar evidencia
Custodio o participante de recuperación	Protege una responsabilidad acotada de recuperación	Reconstruye o controla por sí solo la identidad completa
Proveedor de infraestructura	Opera servicios aprobados de plataforma	Usa acceso operacional como autoridad sobre la verdad de los claims

Una organización puede desempeñar más de una función, pero cada función debe permanecer explícita en política, contratos, control de acceso, evidencia de auditoría y procedimientos de incidentes.

El contrato de confianza

El perfil de integración debe registrar al menos:

1. Finalidad — transacción o servicio para el que se solicita evidencia.
2. Definición de credencial — emisor, tipo, sujeto, semántica de claims, schema y ciclo de vida.
3. Assurance — evidencia y proceso exigidos antes de emitir o aceptar claims.
4. Divulgación — claims mínimos y condiciones de presentación permitidas.
5. Política criptográfica — formatos, algoritmos, relaciones de claves, holder binding y vigencia.
6. Política de estado — expiración, suspensión, revocación, reemplazo y comportamiento de dependencias.
7. Responsable de la decisión — actor que responde por el resultado final y la vía de revisión.
8. Gobierno de datos — finalidad lícita, retención, eliminación, derechos, transferencias y condiciones biométricas.
9. Evidencia operacional — identificadores, versión de política, timestamps, resultados y referencias conservados sin secretos.
10. Gobierno de cambios — compatibilidad, migración, deprecación y notificación de incidentes.

Secuencia de integración de extremo a extremo

Una interacción representativa sigue este patrón:

1. El emisor define una credencial aprobada y la evidencia necesaria para emitirla.
2. El sujeto o titular completa el proofing y flujo de autorización aprobados.
3. El emisor valida evidencia y política y autoriza la creación.
4. Un servicio controlado de firma produce la credencial con clave y algoritmo aprobados.
5. La credencial se entrega al titular mediante una interacción aprobada de Wallet.
6. Un verificador solicita la evidencia mínima para una finalidad declarada.
7. El titular revisa la solicitud y autoriza una presentación adecuada.
8. El verificador valida procedencia, integridad, estado, contexto, relación con el titular y política.
9. La parte usuaria adopta la decisión final.
10. Cada participante conserva la evidencia necesaria para su propia responsabilidad sin recopilar el ciclo completo del titular.

La secuencia puede implementarse con flujos basados en estándares o APIs gobernadas, pero las responsabilidades de confianza no cambian.

Límites de integración

UbID separa cuatro responsabilidades arquitectónicas:

Canales de experiencia

Portales, Wallets, aplicaciones móviles e interfaces de partners recogen la intención del usuario y muestran resultados. No deciden por sí solos la confianza de una credencial ni realizan operaciones criptográficas irrestrictas.

Servicios de confianza

Los servicios de proofing, emisión, verificación, acceso y recuperación evalúan política autoritativa y administran estado del dominio.

Servicios de control de plataforma

Gestión de claves, mensajería, resolución de identificadores, estado, evidencia y componentes compartidos ofrecen controles reutilizables mediante contratos acotados.

Servicios operacionales

Monitoreo, alertas, auditoría e interpretación asistida por IA observan y explican. No modifican silenciosamente el estado de identidad o credenciales.

Patrones de interacción

Intercambio basado en estándares

Las interacciones entre Wallet, emisor y verificador deben utilizar perfiles reconocidos cuando aporten interoperabilidad adecuada. El subconjunto exacto soportado debe fijarse y probarse.

Coordinación mediante APIs gobernadas

Los sistemas institucionales pueden utilizar contratos de UbID Trust API para preparar, validar, aprobar, ejecutar y recuperar resultados. La autorización para descubrir una capacidad es distinta de la autorización para ejecutarla.

Mensajería segura entre agentes

DIDComm puede transportar mensajes protegidos y vinculados a identidad cuando se requiere coordinación asíncrona o agent-to-agent. La mensajería no reemplaza la política de emisión ni de verificación.

Integración de eventos y evidencia

Los sistemas autorizados pueden recibir notificaciones de ciclo de vida o referencias de evidencia. Los eventos deben estar acotados, autenticados, ser resistentes a replay y evitar replicación innecesaria de datos personales.

Minimización de datos en el diseño

Los arquitectos deben distinguir:

• evidencia de origen utilizada para proofing;
• claims incluidos en una credencial;
• disclosures seleccionadas para una presentación;
• resultados de verificación devueltos a la parte usuaria;
• registros operacionales retenidos para responsabilidad.

Son conjuntos de datos distintos y no deben copiarse juntos por defecto. Un verificador suele necesitar un resultado de política y pocos claims, no el documento de origen, credencial completa, inventario de Wallet o registro de proofing.

Modelo de fallas y dependencias

La integración debe definir comportamiento ante:

• metadatos no resolubles del emisor o clave;
• servicio de estado no disponible;
• credencial expirada o reemplazada;
• presentación obsoleta o reproducida;
• formato o algoritmo no soportado;
• divulgación incompleta;
• resultado indeterminado de proofing;
• incompatibilidad de versiones de política;
• timeout del partner o solicitud duplicada;
• degradación operacional.

Los flujos de alto assurance deben fallar de forma cerrada o dirigirse a revisión explícita, no debilitar silenciosamente la política.

Evidencia de integración

Un registro útil puede identificar:

• participantes y transacción;
• finalidad declarada y tipo de credencial solicitado;
• versiones de política y schema;
• comprobaciones de verificación ejecutadas;
• resultado y categoría de razón;
• referencia de autorización o consentimiento;
• timestamps y resultados de dependencias;
• acción de ciclo de vida o referencia de decisión final.

No debe contener llaves privadas, recovery shares, contenido completo de Wallet, templates biométricos ni documentos de origen innecesarios.

Límite de la documentación pública

Este modelo define la arquitectura pública de confianza. Identificadores de tenants, endpoints productivos, schemas exactos de mensajes, credenciales, registros de confianza, código de políticas, mapas de infraestructura, umbrales operacionales y procedimientos de excepción permanecen en documentación controlada de partner o interna.

Consulta Confianza y política, Metadatos públicos y discovery y Funciones y responsabilidades.