Saltar al contenido principal

OpenID para credenciales verificables

OpenID for Verifiable Credentials define contratos de protocolo para dos interacciones distintas:

  • OpenID4VCI coordina la emisión de credenciales entre una Wallet y un emisor de credenciales.
  • OpenID4VP coordina las solicitudes y presentaciones de credenciales entre un verificador y una Wallet.

Los protocolos se apoyan en mecanismos consolidados de OAuth y OpenID, y pueden transportar diferentes formatos de credenciales.

Emisión con OpenID4VCI​

Un flujo de emisión puede incluir:

  1. discovery de metadatos del emisor y configuraciones de credenciales admitidas;
  2. una oferta de credencial u otro mecanismo de inicio;
  3. autorización de la Wallet o del usuario final;
  4. prueba de que la Wallet controla el material de claves requerido;
  5. emisión de una o más credenciales;
  6. entrega diferida o notificación cuando exista soporte;
  7. información de ciclo de vida necesaria para el uso posterior.

El protocolo define cómo se coordina la interacción. No determina si la persona solicitante fue sometida a proofing suficiente ni si el emisor está jurídicamente autorizado para emitir la credencial.

Presentación con OpenID4VP​

Un flujo de presentación puede incluir:

  1. una solicitud del verificador que describa la evidencia requerida;
  2. identidad del verificador e información sobre la finalidad;
  3. evaluación por la Wallet de credenciales compatibles;
  4. revisión y autorización del titular;
  5. creación de una respuesta reciente y vinculada a la audiencia;
  6. validación y evaluación de política por el verificador;
  7. una decisión institucional fuera del protocolo.

Una respuesta de presentación constituye evidencia para una decisión, no la decisión misma.

Digital Credentials Query Language​

OpenID4VP define DCQL, un lenguaje de consulta codificado en JSON mediante el cual un verificador puede describir credenciales aceptables, claims, alternativas y combinaciones.

DCQL puede mejorar la interoperabilidad al hacer más explícitas las solicitudes, pero una consulta técnicamente válida todavía puede ser desproporcionada. UbID exige que el diseño de solicitudes respete la limitación de finalidad y la minimización.

Interacciones en el mismo dispositivo y entre dispositivos​

La interacción entre Wallet y verificador puede ocurrir en el mismo dispositivo o entre dispositivos. Pueden utilizarse códigos QR, deep links, redirects, APIs mediadas por el navegador u otros mecanismos de inicio aprobados, según el perfil.

Cada perfil debe definir protecciones para:

  • autenticidad de la solicitud;
  • validación de redirects y origen;
  • gestión de nonce y state;
  • resistencia a replay;
  • vinculación con la audiencia;
  • cifrado de respuesta cuando sea necesario;
  • consentimiento del usuario y contexto de transacción;
  • timeout y comportamiento ante abandono.

Independencia del formato de credencial​

OpenID4VCI y OpenID4VP son protocolos de transporte y coordinación. Pueden admitir formatos como credenciales basadas en SD-JWT, W3C Verifiable Credentials o documentos móviles ISO cuando el perfil del ecosistema los define.

Compatibilidad de protocolo no implica compatibilidad de formato. Wallets, emisores y verificadores deben acordar el formato exacto, perfil, algoritmos, mecanismo de estado y semántica de claims.

Metadatos y discovery​

Los metadatos públicos pueden describir emisores, authorization servers, configuraciones de credenciales, formatos, algoritmos, endpoints y capacidades de presentación admitidos. Los metadatos permiten automatización, pero no sustituyen el gobierno de confianza.

Un partner debe validar la procedencia de los metadatos, fijar perfiles aprobados, rechazar combinaciones no soportadas y tratar cambios inesperados como eventos controlados de compatibilidad.

Posición de UbID​

La arquitectura de referencia de UbID identifica la emisión alineada con OpenID4VCI y la presentación alineada con OpenID4VP como contratos preferidos de interoperabilidad. Las especificaciones externas son finales de OpenID, pero el estado de capacidad de UbID y los subconjuntos soportados siguen dependiendo del producto y del despliegue.

La documentación y los perfiles de partners deben distinguir:

  • arquitectura alineada;
  • flujo implementado;
  • perfil de interoperabilidad probado;
  • disponibilidad productiva;
  • conformidad certificada o evaluada independientemente.

Estos términos no son intercambiables.

Límite de la documentación pública​

Esta página no publica metadatos productivos, identificadores de clientes, redirect URIs, transaction codes, ofertas de credenciales, valores de sesión, DCQL de clientes, schemas privados ni contratos de endpoints específicos del entorno.

Estándares fuente​

Consulta Integración del emisor, Integración del verificador e Integración de Wallet y titular.