Verificador OpenID4VP: cómo aceptar la cartera europea de identidad digital (EUDI Wallet)
Verificador OpenID4VP para la cartera europea de identidad digital (EUDI Wallet): request objects, consultas DCQL, modos de respuesta, controles SD-JWT VC y mdoc, reglas HAIP del Derecho de la UE, errores comunes y dónde probar.
En resumen
OpenID4VP (OpenID for Verifiable Presentations) es el protocolo que utiliza un verificador para pedir credenciales a una cartera digital y recibir a cambio una presentación firmada. La versión 1.0 pasó a ser una OpenID Final Specification el 10 de julio de 2025, y la cartera europea de identidad digital (EUDI Wallet) la utiliza para la presentación remota.[2][3]
- Envía una solicitud firmada con una consulta DCQL; la cartera devuelve un VP Token.
- Verificas tú mismo la firma del emisor, las divulgaciones, la vinculación de claves y la revocación.
- Para la cartera EUDI, el Derecho de la UE añade normas sobre certificados y registro.
OpenID4VP es la forma en que un sitio web o una aplicación pide a una cartera que demuestre algo sobre una persona, como un nombre o una fecha de nacimiento. El verificador indica qué credenciales y atributos quiere, el usuario los aprueba en la cartera y la cartera devuelve una presentación que el verificador comprueba criptográficamente. En palabras de la propia especificación, "define un protocolo para solicitar y presentar Credenciales".[1]
Esta guía está dirigida a desarrolladores que construyen un verificador OpenID4VP para la cartera EUDI. Trata el objeto de solicitud, DCQL, los modos de respuesta, los flujos entre dispositivos, las comprobaciones de SD-JWT VC y mdoc, las reglas HAIP en el Derecho de la UE, los errores habituales y dónde hacer pruebas.
OpenID4VP en palabras sencillas
OpenID4VP reutiliza la estructura de una solicitud de autorización de OAuth 2.0. El verificador pide el tipo de respuesta vp_token, y una respuesta correcta debe incluir un parámetro vp_token que contenga las presentaciones.[1] No hay ningún código ni token de acceso que intercambiar: los datos llegan en la respuesta.
La cartera autentica a la parte usuaria, comprueba que no pide más de lo que registró, recoge la aprobación del usuario y firma la presentación. Después, la parte usuaria verifica la firma del emisor, el estado de revocación y la vinculación al dispositivo.[3] Los datos de identificación personal (PID) se emiten en dos formatos, SD-JWT VC e ISO/IEC mdoc, y ambos usan hashes con sal para que el usuario pueda compartir algunos atributos y ocultar el resto.[5][3]
- 10 de julio de 2025Especificación finalSe aprueba OpenID4VP 1.0.
- 22 de julio de 2026PublicaciónCIR 2026/1731 (adoptado el 15 de julio de 2026) en el Diario Oficial.
- 23 de julio de 2026ARF v3.0.0Versión actual de la arquitectura.
- 24 de diciembre de 2026CarterasAl menos una por Estado miembro.
- 24 de diciembre de 2027AceptaciónPartes usuarias privadas reguladas.
Desde la especificación final hasta la fecha de aceptación por el sector privado.[2][3][4][5]
Cómo funciona un intercambio con un verificador OpenID4VP
OpenID4VP publica un diseño de referencia para el modo de respuesta direct_post, en el que la cartera envía la respuesta mediante POST a un endpoint del servidor en lugar de enviarla a través del navegador.[1]
La cartera comprueba al verificador y el usuario da su consentimiento
El diseño de referencia direct_post de OpenID4VP 1.0, sección 13.3, simplificado.[1]
- Genere un nonce de "al menos 16 bytes nuevos y criptográficamente aleatorios" por solicitud.
- Envíe a la cartera el request-id del endpoint de respuesta como
state. - Devuelva una URI de redirección con un
response_codenuevo cuando la cartera haga el envío. - Obtenga el VP Token con el transaction-id y ese código y, después, compruebe el nonce.
El response_code impide la fijación de sesión, en la que un atacante reenvía a la cartera de una víctima la solicitud que usted ha emitido. La especificación indica que no sirve entre dispositivos distintos y recomienda mecanismos adicionales en ese caso.[1]
Vídeo pendiente: flow-eudi-openid4vp
Una presentación OpenID4VP desde una cartera EUDI, de principio a fin.
El objeto de solicitud de OpenID4VP y los identificadores de cliente
El client_id empieza por un prefijo de identificador de cliente que indica a la cartera cómo autenticar al verificador.[1] Las solicitudes de gran tamaño se transmiten por referencia: la cartera obtiene el objeto de solicitud firmado desde una request_uri. Para los códigos QR, la especificación recomienda direct_post con request_uri, ya que la solicitud "podría no caber en un código QR".[1]
| Prefijo | Cómo autentica la cartera al verificador | Solicitud firmada |
|---|---|---|
redirect_uri | El identificador es la URI de redirección o de respuesta | No se puede firmar |
x509_san_dns | Nombre DNS en el SAN del certificado hoja | Obligatoria |
x509_hash | Hash SHA-256 del certificado hoja | Obligatoria |
decentralized_identifier | Clave del DID Document | Obligatoria |
verifier_attestation | JWT de atestación de un emisor en el que confía la cartera | Obligatoria |
openid_federation | Cadena de confianza de la federación | Según OpenID Federation |
Prefijos de identificador de cliente (Client Identifier Prefixes), OpenID4VP 1.0, sección 5.9.[1]
Para los verificadores EUDI, el Derecho de la UE determina el prefijo: el certificado final «para su uso con el Client Identifier Prefix x509_hash será un certificado de acceso de parte usuaria conforme a lo especificado en ETSI TS 119 475», y un elemento de verifier_info «incluirá el certificado de registro».[5]
Consultas DCQL: solicite lo que ha registrado
El Digital Credentials Query Language (DCQL) es la consulta JSON que indica las credenciales y los atributos que se solicitan. Contiene una matriz credentials obligatoria y una matriz credential_sets opcional. Cada consulta de credencial necesita un id, un format y un objeto meta.[1] El ejemplo de SD-JWT VC de la especificación:[1]
{ "credentials": [ { "id": "my_credential", "format": "dc+sd-jwt", "meta": { "vct_values": [ "https://credentials.example.com/identity_credential" ] }, "claims": [ {"path": ["last_name"]}, {"path": ["first_name"]}, {"path": ["address", "street_address"]} ] } ] }
Para un mdoc, el formato es mso_mdoc y meta incluye un doctype_value.[1] Para el PID, sustituya el tipo y los nombres de los atributos por los del PID. Los atributos obligatorios del PID son apellidos, nombre, fecha de nacimiento, lugar de nacimiento y nacionalidad.[7]
require_cryptographic_holder_bindingtiene el valor true por defecto. Manténgalo: hace que la cartera devuelva una prueba de vinculación de clave.[1]trusted_authoritiessolo filtra lo que ofrece la cartera. Los verificadores «deben verificar por sí mismos que el emisor de una presentación recibida es de confianza».[1]- Las partes usuarias «no solicitarán a los usuarios que faciliten datos distintos de» los que ellas registraron, y la cartera lo comprueba.[4][3]
Modos de respuesta de OpenID4VP
El modo de respuesta determina cómo se devuelve el VP Token. El valor por defecto para vp_token es fragment, en el fragmento de la URI de redirección.[1]
| Modo de respuesta | Adónde va el VP Token | Cifrado |
|---|---|---|
fragment | Fragmento de la URI de redirección, a través del navegador | No |
direct_post | HTTP POST a la response_uri | No |
direct_post.jwt | HTTP POST de un JWT cifrado | Sí |
dc_api | De vuelta a través de la Digital Credentials API | No |
dc_api.jwt | Igual, pero cifrado | Sí |
Modos de respuesta en OpenID4VP 1.0.[1]
Con direct_post, response_uri es obligatorio y redirect_uri debe estar ausente. Si no, la cartera devuelve invalid_request.[1] La EVO Wallet de Moldavia, por ejemplo, documenta OpenID4VP 1.0 con direct_post.jwt en un flujo en el mismo dispositivo, mdoc ISO/IEC 18013-5 perfilado conforme a OpenID4VC HAIP 1.0 y una IETF Token Status List para la revocación.[11]
Mismo dispositivo, entre dispositivos y la Digital Credentials API
El ARF enumera las combinaciones remotas admitidas: OpenID4VP combinado con un mecanismo de transmisión basado en redirecciones y esquemas de URI personalizados; OpenID4VP o ISO/IEC 18013-7 combinados con la W3C Digital Credentials API; y, de forma opcional, ISO/IEC 18013-7 con redirecciones y esquemas de URI personalizados.[3]
Mismo dispositivo
Esquema de URI personalizado
- El navegador pasa openid4vp:// al sistema operativo
- La cartera se abre en el mismo teléfono
ARF 4.4.3.1
Entre dispositivos
Código QR
- El ordenador muestra un código QR para escanear
- Expuesto al phishing y a la retransmisión
ARF 4.4.3.1
API del navegador
Digital Credentials API
- El navegador transmite el origen verificado
- Activada por defecto en Chrome 141
OpenID4VP, Apéndice A
Tres formas en que una cartera recibe una solicitud OpenID4VP.[3][1][10]
El ARF indica que los esquemas de URI personalizados «no se recomiendan para flujos entre dispositivos» y señala la Digital Credentials API como alternativa.[3] A través de la API, la cartera conoce el origen del verificador tal como lo autentica el navegador, «lo cual es importante para la resistencia al phishing».[1] La especificación del W3C sigue siendo un borrador.[9] Lo que ve el usuario en un teléfono:
Verifique su identidad
Este sitio web solicita sus datos a su cartera.
1El navegador envía una URI openid4vp:// al sistema operativo.[3]
Comprobando la solicitud
La cartera se abre y se conecta con la parte usuaria.
2La cartera autentica a la parte usuaria y comprueba lo que la parte usuaria registró.[3]
Elija qué compartir
- ApellidoSe comparte
- Fecha de nacimientoSe comparte
- DirecciónNo se comparte
Compartir
3El usuario aprueba los atributos.[3]
Datos recibidos
4La cartera envía la respuesta y devuelve al usuario.[1]
Verificación paso a paso de una presentación SD-JWT VC
Una presentación SD-JWT VC contiene el JWT firmado por el emisor, las divulgaciones que el usuario ha revelado y un Key Binding JWT. El verificador «DEBE validar cada Verifiable Presentation individual» y rechazar cualquiera con un nonce incorrecto.[1]
1Verificar la firma del emisor
La clave se encadena a un proveedor de PID o de atestaciones de confianza.
2Comprobar cada divulgación
El hash de cada una coincide con un digest del payload firmado.
3Verificar el Key Binding JWT
Firma con la clave del titular. El nonce y la audiencia coinciden.
4Comprobar la revocación
Consultar la lista de estado del emisor.
Todas las comprobaciones son correctas
Usar los atributos revelados
Rechazar y ofrecer otra vía
Las comprobaciones del verificador sobre una presentación SD-JWT VC.[1][3]
Firma del emisor. El ARF la sitúa en primer lugar entre las comprobaciones de la parte usuaria. Los anclajes de confianza proceden de las Trusted Lists (ETSI TS 119 612) y de las Lists of Trusted Entities (ETSI TS 119 602).[3]
Divulgaciones. El payload firmado contiene un array _sd de digests. Cada divulgación consta de una sal, un nombre de atributo y un valor, por ejemplo ["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"].[1] Calcule el hash de cada una y localice su digest. Si no hay coincidencia, el emisor no la firmó.
Key Binding JWT. Cuando se exige la vinculación al titular, la cartera «DEBE devolver un SD-JWT con un Key Binding JWT». Su nonce debe coincidir con el nonce de su solicitud y su aud con su identificador de cliente o, a través de la Digital Credentials API, con su origen precedido de origin:.[1] El ejemplo de la especificación:
{ "nonce": "n-0S6_WzA2Mj", "aud": "x509_san_dns:client.example.org", "iat": 1709838604, "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4" }
Revocación. La parte usuaria verifica que el proveedor «no ha revocado el PID ni la atestación».[3] La EVO Wallet de Moldavia, por ejemplo, documenta una IETF Token Status List para ello.[11]
Nota
El retrato del PID solo será obligatorio a partir del 11 de agosto de 2028, así que no planifique una comparación facial con el retrato de la cartera antes de esa fecha.[5]
Presentaciones mdoc mediante ISO/IEC 18013-7, en resumen
En un mdoc, el VP Token contiene un DeviceResponse de ISO/IEC 18013-5 codificado en base64url que «contiene una firma o un MAC sobre el SessionTranscript», incluida una estructura de handover de OpenID4VP.[1] Ese handover vincula el mdoc a su solicitud, del mismo modo que el nonce y la audiencia vinculan un SD-JWT VC.
Atención
El Derecho de la UE aplica el «anexo C de ISO/IEC 18013-7:2025» para mdoc a través de la Digital Credentials API.[5] ISO indica que la edición de 2024 de 18013-7 está retirada y sustituida, así que compruebe qué edición implementa su biblioteca.[8]
Nuestra comparativa entre SD-JWT VC y mdoc explica cuándo encaja cada formato.
Qué añade el perfil HAIP para los verificadores EUDI
El High Assurance Interoperability Profile (HAIP) reduce las opciones de OpenID4VP. El ARF ya lo exige para la emisión y afirma que su uso «es necesario para garantizar la interoperabilidad».[3] Para la presentación, el CIR 2026/1731 establece un «perfil OpenID4VC-HAIP» y un «perfil ISO/IEC-mdoc».[5]
| Requisito | Para su verificador | Fuente |
|---|---|---|
| Certificado de acceso | Firme con un certificado x509_hash de acceso de parte usuaria, ETSI TS 119 475 | CIR 2026/1731[5] |
| Certificado de registro | Inclúyalo en verifier_info | CIR 2026/1731[5] |
| Registro | Regístrese donde esté establecido | eIDAS art. 5b(1)[4] |
| Comprobaciones de la cartera | Las unidades de cartera validan los certificados de registro solo a partir del 11 de agosto de 2028; no es un plazo de registro | CIR 2026/1731[5] |
El certificado de registro «describe el uso previsto de la parte usuaria e indica los atributos» que ha registrado, y el reglamento de registro se aplica a partir del 24 de diciembre de 2026.[6] La fecha del 11 de agosto de 2028 solo afecta a la comprobación de ese certificado por parte de la cartera, no al registro.[5] Alemania lo resume así: una organización «recibe un certificado de acceso y de registro para la organización y el caso de uso».[12] Nuestra guía para partes usuarias de la cartera EUDI trata el registro en detalle.
Errores habituales al crear un verificador OpenID4VP
| Error | Solución |
|---|---|
| Nonces reutilizados o cortos | Al menos 16 bytes aleatorios nuevos por solicitud[1] |
| Sin comprobación de audiencia | Compare aud con su identificador de cliente (Client Identifier) o su origen[1] |
| Solicitar datos no registrados | Construya la consulta DCQL a partir de su registro[4] |
| Códigos QR con URI personalizado entre dispositivos | Prefiera la Digital Credentials API[3] |
Confiar en trusted_authorities | Valide usted mismo el emisor frente a las listas de confianza[1] |
| Omitir la revocación | Compruebe el estado cada vez[3] |
Firmar con el prefijo redirect_uri | No se puede firmar; use x509_hash[1][5] |
La cartera también es voluntaria: el acceso «no se restringirá ni se hará desventajoso en modo alguno» para las personas que no la utilicen, por lo que su verificador convive con otra vía.[4]
Recursos de prueba
Empiece por el software de referencia y las pruebas de conformidad antes de probar con carteras nacionales.
- Ejecute las pruebas de conformidad en conformance.eudi.dev.[3]
- Lea la documentación de la implementación de referencia en docs.eudi.dev, que es documentación, no pruebas.[3]
- Estudie el verificador de demostración del Banco Nacional de Moldavia y su código fuente.[13]
- Consulte el borrador de la Digital Credentials API antes de confiar en la vía del navegador.[9]
Para las fechas en las que se basa su plan de pruebas, consulte Plazos de la cartera EUDI para 2026 y 2027.
Cómo ayuda Didit con la verificación con la cartera EUDI
La aceptación de la cartera EUDI llegará pronto a Didit: está en nuestra hoja de ruta, alineada con el calendario de la cartera EUDI, en el mismo flujo de trabajo que usa hoy. Mientras tanto, ya puede verificar a personas a distancia.
- Cinco eID nacionales funcionan hoy en Didit mediante carteras de identidad digital: MitID, BankID Sweden, Finnish Trust Network, Smart-ID y Mobile-ID. Consulte verificación de eID.
- Si una persona no tiene eID, el flujo recurre a la verificación de documentos con lectura del chip NFC, prueba de vida y comparación facial, configurado por país. Una comprobación KYC completa cuesta $0.33.
- El cribado AML se ejecuta en el mismo flujo por $0.20.
Conserva sus obligaciones como parte usuaria. La documentación de la cartera muestra cómo se activan las eID por país.
Lo que aporta Didit
- Inicios de sesión con eID nacionales y la vía documental en un único flujo de trabajo
- Las pruebas de cada comprobación
Le sigue correspondiendo
- Su registro como parte usuaria de la cartera
- Sus políticas y la decisión de alta del cliente
Planifique con nosotros su ruta hacia la cartera EUDI
Indíquenos sus países y su caso de uso, y empiece hoy con identidades electrónicas (eID) nacionales y documentos.
Puntos clave
- OpenID4VP 1.0 es una especificación final de OpenID desde el 10 de julio de 2025.
- Envía una consulta DCQL limitada por tu registro y con un nonce nuevo.
- Verifique la firma del emisor, cada divulgación, el Key Binding JWT y la revocación.
- Los verificadores EUDI firman con un certificado de acceso de parte usuaria
x509_hash. - Las partes usuarias privadas incluidas en el ámbito aceptan la cartera a más tardar el 24 de diciembre de 2027.
Preguntas frecuentes
¿Qué es OpenID4VP?
OpenID for Verifiable Presentations es un protocolo para solicitar y presentar credenciales. La cartera devuelve presentaciones firmadas en un VP Token, sin código de autorización ni token de acceso que intercambiar. La versión 1.0 pasó a ser una OpenID Final Specification el 10 de julio de 2025.[1][2]
¿Utiliza la cartera EUDI OpenID4VP?
Sí, para la presentación remota, junto con ISO/IEC 18013-7. El Derecho de la UE establece un perfil OpenID4VC-HAIP y un perfil ISO/IEC-mdoc.[3][5]
¿Qué es DCQL?
El Digital Credentials Query Language es la consulta JSON que indica las credenciales y los atributos que quiere un verificador. La cartera devuelve las presentaciones que coinciden. Para la cartera EUDI, solicite solo los atributos que registró.[1][4]
¿Qué modo de respuesta debe usar un verificador EUDI?
Un verificador del lado del servidor usa direct_post o el modo cifrado direct_post.jwt. A través de la Digital Credentials API, los modos son dc_api y dc_api.jwt.[1]
¿Cómo verifico el Key Binding JWT?
Comprueba su firma con la clave vinculada en la credencial y, después, comprueba su nonce y su audiencia frente a tu solicitud. A través de la Digital Credentials API, la audiencia es tu origen.[1]
¿Qué prefijo de identificador de cliente usan los verificadores EUDI?
x509_hash, con un certificado de acceso de parte usuaria conforme a ETSI TS 119 475. El certificado de registro va en verifier_info.[5]
¿Puedo usar un código QR entre dispositivos?
Puede, pero el ARF no recomienda esquemas de URI personalizados entre dispositivos por los ataques de phishing y de retransmisión. Señala la Digital Credentials API como alternativa.[3]
¿Puedo hacer la comparación facial con el retrato de la cartera?
Todavía no de forma fiable. El retrato solo pasa a ser un dato PID obligatorio a partir del 11 de agosto de 2028.[5]
¿Dónde puedo probar un verificador OpenID4VP?
Ejecuta las pruebas de conformidad en conformance.eudi.dev y consulta la documentación de la implementación de referencia en docs.eudi.dev. El banco central de Moldavia también publicó un verificador de demostración con su código fuente.[3][13]
Fuentes
- OpenID for Verifiable Presentations 1.0, OpenID Foundation, especificación final.
- Aprobada la especificación final de OpenID for Verifiable Presentations 1.0, OpenID Foundation, 10 de julio de 2025.
- Architecture and Reference Framework v3.0.0, eu-digital-identity-wallet en GitHub, versión del 23 de julio de 2026.
- Reglamento (UE) 2024/1183 (eIDAS 2), EUR-Lex, Diario Oficial de 30 de abril de 2024.
- Reglamento de Ejecución (UE) 2026/1731 de la Comisión, EUR-Lex, Diario Oficial de 22 de julio de 2026.
- Reglamento de Ejecución (UE) 2025/848 de la Comisión relativo al registro de las partes usuarias de carteras, EUR-Lex, Diario Oficial de 7 de mayo de 2025.
- Reglamento de Ejecución (UE) 2024/2977 de la Comisión sobre los datos de identificación de la persona, EUR-Lex, Diario Oficial de 4 de diciembre de 2024.
- ISO/IEC 18013-7, página de la norma en ISO.
- Digital Credentials, borrador del W3C.
- Lanzamiento de la Digital Credentials API, Chrome for Developers.
- Guía para desarrolladores de EVO Wallet, Gobierno de Moldavia, egov4dev.
- Preguntas frecuentes sobre la cartera EUDI, eudi-wallet.gov.de.
- Verificador de demostración del BNM, Gobierno de Moldavia, egov4dev.
OpenID4VP es la parte de la cartera EUDI con la que más trabajan los desarrolladores, y es lo bastante estable para desarrollar sobre ella. Consulte cómo enfoca Didit la aceptación de carteras en la página de la solución de cartera EUDI, y el panorama general en nuestra visión general de eIDAS 2.
Verifique a personas a distancia mientras se despliegan las carteras
Utilice ya las identidades electrónicas (eID) nacionales y la vía documental, y hable con nosotros sobre la cartera EUDI.
Artículos relacionados
- Integración con Cl@ve en España: quién puede conectarse y qué usar en su lugar
- Verificación PhilSys: cómo comprueban las empresas el National ID
- Verificador OpenID4VP: cómo aceptar la cartera europea de identidad digital (EUDI Wallet)
- Reglamento eIDAS explicado: qué cambia eIDAS 2 (2024/1183)
- API de Smart-ID: guía para desarrolladores de la RP API v3
- Identidad digital nacional en el mundo: modelos, líderes y estándares