Estándares e interoperabilidad
UbID está diseñado como un tejido de confianza interoperable, no como un silo cerrado de identidad. Los estándares abiertos definen cómo se resuelven identificadores, se representan credenciales, las Wallets interactúan con emisores y verificadores, los usuarios se autentican, los servicios reciben autorización, los agentes intercambian mensajes protegidos y los asistentes de software descubren capacidades gobernadas.
Los estándares establecen contratos comunes entre participantes que pueden utilizar productos y stacks tecnológicos internos diferentes. No eliminan la necesidad de gobierno, política, ingeniería de seguridad, controles de privacidad, pruebas ni responsabilidad institucional.
Capas de interoperabilidad
| Capa | Estándares o perfiles principales | Propósito en el modelo UbID |
|---|---|---|
| Identificación y resolución | DID Core y did:web | Publicar identificadores resolubles, métodos de verificación y referencias de servicio. |
| Semántica de credenciales | W3C Verifiable Credentials Data Model | Expresar de forma coherente emisor, titular, sujeto, claims, schema, estado y evidencia. |
| Divulgación selectiva | SD-JWT y perfiles de credenciales basados en SD-JWT | Permitir que el titular divulgue claims seleccionados en lugar del payload completo. |
| Emisión de credenciales | OpenID4VCI | Coordinar ofertas, autorización, prueba y entrega entre una Wallet y un emisor. |
| Presentación de credenciales | OpenID4VP y DCQL | Solicitar y devolver credenciales o presentaciones adecuadas para una finalidad definida. |
| Autenticación web | WebAuthn y FIDO2 | Proporcionar autenticación con clave pública resistente al phishing y passkeys. |
| Federación y sesiones | OpenID Connect | Establecer sesiones web autenticadas y assertions interoperables de identidad. |
| Autorización de APIs | OAuth 2.0, PKCE y buenas prácticas de seguridad vigentes | Delegar acceso acotado a APIs protegidas. |
| Mensajería de agentes | DIDComm Messaging | Intercambiar mensajes cifrados vinculados a identidad con independencia de un transporte concreto. |
| IA y herramientas | Model Context Protocol | Exponer resources y tools a asistentes autorizados mediante un contrato de integración gobernado. |
Otros estándares pueden contribuir a controles especializados, incluidos JSON Schema para validación, JOSE y COSE para envelopes criptográficos, formatos de listas de estado, OHTTP y HPKE para privacidad de transporte y estándares poscuánticos para criptoagilidad a largo plazo. Su uso debe declararse en el producto o perfil de partner correspondiente, y no inferirse del nombre de la plataforma.
Cuatro dimensiones de la interoperabilidad
Sintaxis
Los participantes deben acordar cómo se codifica y transporta la información. Entre los ejemplos se incluyen JSON, JWT, JWS, JWK, HTTP y envelopes de mensajes DIDComm.
Semántica
Un objeto JSON técnicamente válido no es interoperable si los participantes asignan significados diferentes a sus campos. Deben gobernarse tipos de credenciales, definiciones de claims, versiones de schemas, significados de estado, niveles de assurance y definiciones de finalidad.
Confianza
Interoperabilidad no significa aceptar a todos los emisores, claves, algoritmos, Wallets o verificadores. Cada institución sigue aplicando registros de confianza, política de emisores, política de algoritmos, controles de estado, requisitos de assurance y controles de riesgo.
Operaciones
La interoperabilidad productiva también necesita negociación de versiones, discovery de metadatos, manejo de errores, protección contra replay, ciclo de vida, pruebas de conformidad, monitoreo y gobierno del cambio.
La madurez del estándar y la madurez de UbID son diferentes
Una especificación puede ser final mientras una capacidad particular de UbID continúa planificada, limitada o disponible solo para partners. A la inversa, UbID puede implementar un perfil controlado basado en un borrador, identificando con claridad la versión fijada y sus obligaciones de migración.
Por ello, el portal público separa:
- madurez externa de la especificación;
- función arquitectónica asignada;
- estado actual de la capacidad UbID;
- subconjunto habilitado en un despliegue específico;
- evidencia de conformidad disponible para revisión.
Ninguna página de estándares debe interpretarse como una afirmación universal de conformidad para todos los productos, tenants, tipos de credenciales o entornos UbID.
Gobierno de versiones y perfiles
Un despliegue interoperable debe registrar:
- versión exacta de la especificación o perfil;
- funciones obligatorias y opcionales admitidas;
- formatos de credenciales y algoritmos permitidos;
- requisitos de metadatos y discovery;
- comportamiento de errores y reintentos;
- reglas de privacidad y retención;
- pruebas de conformidad y limitaciones conocidas;
- política de migración y deprecación.
Este enfoque basado en perfiles permite que UbID evolucione sin modificar silenciosamente el contrato de confianza entre emisores, titulares, Wallets, verificadores y partners.
Qué no reemplazan los estándares
Los estándares abiertos no determinan si una institución está autorizada para emitir un claim, si el proofing fue suficiente, si la solicitud de un verificador es proporcional, si una credencial debe aceptarse para una transacción o si el tratamiento es lícito en una jurisdicción.
Estas decisiones siguen correspondiendo al gobierno, la política, el assurance y los actores institucionales responsables.
Límite de la documentación pública
El portal público explica estándares, funciones, conceptos de ciclo de vida y posiciones aprobadas de interoperabilidad. Excluye schemas privados, perfiles de clientes, inventarios de endpoints, registros de clientes, trust lists, identificadores de claves criptográficas, routing de recuperación, extensiones internas de protocolos, brechas de conformidad y credenciales operacionales.
Continúa con Identificadores descentralizados, Credenciales verificables y SD-JWT u OpenID para credenciales verificables.