Construir con UbID

Construir con UbID significa integrar un ciclo de confianza, no limitarse a invocar un endpoint de identidad. Una implementación satisfactoria comienza definiendo quién está autorizado para emitir evidencia, quién la controla, quién la solicita, qué política determina su aceptación y qué evidencia debe permanecer disponible después de la transacción.

UbID proporciona un modelo de integración basado en funciones para emisores, titulares, Wallets, verificadores, partes usuarias, custodios y servicios operacionales. Los estándares abiertos aportan contratos de intercambio; la política institucional aporta significado, autoridad y responsabilidad.

Comenzar con la pregunta de confianza

Antes de seleccionar un protocolo o API, la institución debe formular la pregunta que necesita responder. Por ejemplo:

• ¿Esta persona mantiene actualmente una relación con una institución aprobada?
• ¿Este profesional posee una cualificación válida para la actividad solicitada?
• ¿Quien presenta tiene derecho a utilizar esta credencial?
• ¿Este claim derivado de un documento está respaldado por evidencia suficiente?
• ¿Este dispositivo y sesión son adecuados para la operación solicitada?

La pregunta determina los claims mínimos, emisores aceptables, nivel de assurance, contexto de presentación, requisitos de estado, retención y responsable de la decisión final.

Recorrido público de integración

Una integración típica avanza por estas etapas:

1. Definir funciones y finalidad — identificar emisor, titular, Wallet, verificador, parte usuaria, responsable, encargado y propietarios operacionales.
2. Diseñar el perfil de confianza — definir tipo de credencial, semántica de claims, emisores aceptados, algoritmos, estado, assurance, divulgación y resultados de política.
3. Seleccionar el patrón de intercambio — elegir contratos aprobados de emisión, presentación, mensajería, autenticación o APIs.
4. Descubrir capacidades — resolver identificadores públicos y metadatos sin tratar discovery como autorización.
5. Prototipar con datos sintéticos — validar la interacción sin datos personales reales ni credenciales productivas.
6. Completar onboarding controlado — acordar schemas, entornos, responsabilidades de seguridad, soporte y evidencia.
7. Probar casos positivos y negativos — confirmar interoperabilidad, privacidad, resistencia a replay, ciclo de vida y decisiones fail-closed.
8. Aprobar uso productivo — registrar perfil, versiones, responsables, controles y readiness operacional exactos.
9. Operar y evolucionar — monitorear resultados, rotar claves, administrar estado, revisar políticas y coordinar cambios.

Dominios de integración

Dominio	Objetivo de integración	Productos UbID principales
Emisión	Convertir evidencia gobernada en una credencial firmada y entregable	Credential Cloud, Proof, KeyVault, Trust API
Titular y Wallet	Proteger credenciales, obtener autorización y producir presentaciones	Wallet, Access, Recover, Connect
Verificación	Validar procedencia, integridad, estado, contexto y política	Proof, Trust API, Connect
Discovery de confianza	Resolver identificadores, claves públicas, perfiles admitidos y estado	Connect, Trust API, Credential Cloud
Autenticación y acceso	Establecer una sesión segura de usuario o dispositivo	Access, Wallet
Recuperación y continuidad	Restituir acceso controlado sin crear un secreto universal de recuperación	Recover, Wallet, Connect, KeyVault
Operaciones	Observar postura de servicios y conservar evidencia explicable	Pulse, Sentinel AI

Contratos estables, componentes internos reemplazables

Las integraciones externas deben depender de contratos versionados, no de bases de datos internas, nombres de contenedores, librerías de implementación o topología de servicios. UbID Trust Gateway y las APIs de productos proporcionan una frontera controlada entre protocolos externos y dominios internos de confianza.

Esta separación permite:

• evolución independiente de componentes internos;
• validación explícita en límites de confianza;
• autorización y evidencia coherentes;
• adaptación de protocolos sin exponer estado interno;
• responsabilidades más claras de incidentes y soporte;
• menor acoplamiento entre partners y operaciones de plataforma.

Documentación pública y documentación para partners

Este portal describe arquitectura pública, responsabilidades, patrones de ciclo de vida, posición sobre estándares, conceptos de metadatos, etapas de onboarding y límites de publicación.

La documentación controlada para partners puede añadir:

• perfiles exactos de APIs y protocolos;
• metadatos específicos del entorno;
• definiciones y schemas aprobados de credenciales;
• requisitos de registro y autorización de clientes;
• vectores de prueba y casos de conformidad;
• canales de soporte y niveles de servicio;
• procedimientos de cambio, deprecación y aprobación productiva.

Credenciales productivas, trust lists privadas, configuración de clientes, material criptográfico, topología interna y operaciones administrativas nunca se distribuyen mediante el portal público.

Principios de integración

Toda integración debe preservar estas reglas:

• Finalidad antes que datos — solicitar solo la evidencia requerida para una transacción declarada.
• Funciones antes que endpoints — asignar autoridad y responsabilidad antes de seleccionar interfaces.
• Política antes que automatización — definir qué es aceptable antes de automatizar una decisión.
• Verificación antes que aceptación — la validez criptográfica es solo una entrada de la política institucional.
• Autorización antes que presentación — el titular debe comprender qué se solicita y para qué.
• Ciclo de vida antes que lanzamiento — definir expiración, estado, renovación, reemplazo, revocación y recuperación.
• Evidencia sin secretos — conservar decisiones explicables sin registrar llaves privadas, contenido completo de Wallet ni datos personales innecesarios.
• Cambio versionado — fijar perfiles y tratar cambios inesperados de metadatos o comportamiento como eventos controlados de compatibilidad.

Preguntas de readiness

Antes de solicitar acceso como partner, el equipo de integración debe poder responder:

• ¿Qué organización es autoritativa para cada claim?
• ¿Qué credenciales y claims son realmente necesarios?
• ¿Qué assurance se necesita y cómo se evidenciará?
• ¿Quién es responsable de la decisión final de negocio o jurídica?
• ¿Qué identificadores y metadatos deben ser resolubles públicamente?
• ¿Cómo se administrarán estado, expiración, reemplazo y revocación?
• ¿Qué ocurre si una dependencia no está disponible o el resultado es indeterminado?
• ¿Qué datos se conservarán, durante cuánto tiempo y bajo qué función?
• ¿Qué pruebas negativas deben superarse antes de producción?
• ¿Quién es responsable de rotación de claves, incidentes, soporte y notificación de cambios?

Continúa con Modelo de integración, Integración del emisor, Integración del verificador u Onboarding de partners.