SD-JWT VC frente a mdoc (ISO/IEC 18013-5): comparativa de formatos de la cartera EUDI
SD-JWT VC vs mdoc (ISO/IEC 18013-5) para desarrolladores: divulgación selectiva, key binding, OpenID4VP, ISO/IEC 18013-7, qué exige el Reglamento de Ejecución (UE) 2026/1731 para el PID y qué formato necesita un verificador.
En resumen
SD-JWT VC y mdoc (ISO/IEC 18013-5) son los dos formatos de credencial que toda cartera europea de identidad digital (EUDI Wallet) tiene que admitir. SD-JWT VC es JSON y está pensado para el uso a distancia. mdoc es CBOR binario y es el único que también funciona en proximidad.[1]
- Ambos ocultan y revelan atributos con la misma idea: hashes con sal firmados por el emisor.[1]
- Desde el Reglamento de Ejecución (UE) 2026/1731, los datos de identificación personal se expiden en ambos formatos.[2]
- Un verificador remoto puede leer cualquiera de los dos mediante OpenID4VP. Un lector de proximidad necesita mdoc.[1]
Una SD-JWT VC es una credencial verificable empaquetada como un JSON Web Token firmado cuyas declaraciones pueden revelarse una a una. Un mdoc es un documento móvil en el formato de la ISO/IEC 18013-5, la norma escrita en origen para los permisos de conducir móviles. El Marco de Arquitectura y Referencia (ARF) de la cartera EUDI establece ambos como obligatorios para las carteras, y un tercer formato, el W3C Verifiable Credentials Data Model 2.0, como opcional y «destinado únicamente a EAA no cualificadas».[1]
Esta guía compara los dos formatos para los desarrolladores que construyen un verificador, a partir del ARF v3.0.0, el texto de OpenID for Verifiable Presentations (OpenID4VP) 1.0 y el Diario Oficial. PID significa datos de identificación personal.
Qué es una SD-JWT VC
El ARF describe las «SD-JWT-based Verifiable Credentials» como un formato de datos y unas reglas de procesamiento para expresar credenciales verificables, donde SD-JWT «significa 'Selectively Disclosable JSON Web Token'».[1] Abarca la codificación JSON, un mecanismo de prueba con divulgación selectiva y una vinculación al dispositivo opcional.[1]
En OpenID4VP el identificador de formato es dc+sd-jwt, y una consulta indica el tipo de credencial mediante vct_values.[4] El ejemplo de carga útil expedida que da la especificación, reducido a dos de sus ocho resúmenes:[4]
{ "_sd": [ "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4", "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo" ], "vct": "https://credentials.example.com/identity_credential", "_sd_alg": "sha-256", "cnf": { "jwk": { "kty": "EC", "crv": "P-256" } } }
Nota
SD-JWT VC deja muchas opciones abiertas. El ARF indica que el High Assurance Interoperability Profile (HAIP) «es necesario para garantizar la interoperabilidad entre las unidades de cartera y las partes usuarias».[1] Desarrolle conforme a HAIP.
Qué es un mdoc (ISO/IEC 18013-5)
La ISO/IEC 18013-5 define los atributos del permiso, su codificación en Concise Binary Object Representation (CBOR), espacios de nombres que evitan que los identificadores colisionen, un mecanismo de prueba con divulgación selectiva, una vinculación al dispositivo obligatoria y el intercambio en proximidad.[1]
Solo el modelo de datos del permiso es específico de la conducción. El ARF señala que todos los demás aspectos «son genéricos y pueden utilizarse para cualquier otro tipo de declaración, incluidos los PID».[1]
OpenID4VP describe estas credenciales como «codificadas en CBOR y protegidas mediante COSE_Sign1» y les asigna el identificador de formato mso_mdoc. Una consulta indica el tipo de documento mediante doctype_value.[4]
Nota
Se está preparando una norma general para presentar documentos móviles, la ISO/IEC 23220-4. El ARF indica que «todavía no está terminada» y sigue remitiendo a la ISO/IEC 18013-5.[1]
Cómo funciona la divulgación selectiva en cada formato
La divulgación selectiva permite al usuario compartir algunos atributos y ocultar el resto, mientras el verificador sigue comprobando la firma del emisor. eIDAS 2 exige que las carteras lo hagan posible.[6] El ARF denomina el mecanismo de SD-JWT «hashes con sal» y afirma que «es conceptualmente idéntico al mecanismo utilizado con el mismo fin en [ISO/IEC 18013-5]».[1]
JSON
SD-JWT VC
- El emisor firma un JWT que contiene resúmenes, no valores
- Cada declaración oculta viaja como una divulgación independiente
- La cartera envía solo las divulgaciones aprobadas
OpenID4VP 1.0, apéndice B.3
CBOR
mdoc (ISO/IEC 18013-5)
- El emisor firma hashes con sal de los elementos de datos
- Los elementos de datos se ubican en espacios de nombres
- La cartera devuelve solo los elementos aprobados
ARF v3.0.0, secciones 5.4.2 y 5.4.3
Un mecanismo, dos codificaciones.[1][4]
En el ejemplo anterior, la matriz _sd contiene resúmenes SHA-256. Cada divulgación es una matriz con un valor aleatorio, el nombre y el valor de la declaración. Para el nombre de pila es ["2GLC42sKQveCfGfryNRN9w", "given_name", "John"], y su hash es el primer resumen de la lista. El verificador calcula el hash de cada divulgación que recibe y busca el resumen en la carga útil firmada.[4]
Las declaraciones se referencian de forma distinta. En una credencial JSON, una ruta de declaraciones es una lista de claves como ["address", "street_address"]. En un mdoc, la ruta «contiene dos elementos de tipo string»: el espacio de nombres y el identificador del elemento de datos, por ejemplo ["org.iso.18013.5.1", "first_name"].[4]
Atención
La tabla de atributos del PID no incluye ningún atributo "mayor de 18". Los obligatorios son apellidos, nombre, fecha de nacimiento, lugar de nacimiento y nacionalidad.[3] La divulgación selectiva oculta atributos; no convierte una fecha de nacimiento en un sí o un no.
Vinculación de clave e interacción con el dispositivo (device engagement)
La vinculación al dispositivo asocia una credencial a claves guardadas en la cartera del usuario, de modo que no se puede clonar. El verificador la comprueba pidiendo a la cartera que firme datos aleatorios nuevos con la clave privada que corresponde a la clave pública incluida en la credencial.[1] Los nombres difieren: "En [ISO/IEC 18013-5] se denomina 'mdoc authentication'. En [SD-JWT VC] se denomina 'key binding'."[1]
| Pregunta | SD-JWT VC | mdoc (ISO/IEC 18013-5) |
|---|---|---|
| Nombre de la prueba | Key binding | mdoc authentication |
| Exigida por el formato | Opcional en la especificación | Obligatoria en el estándar |
| Dónde se encuentra la clave del titular | La declaración cnf | Dentro del mdoc firmado por el emisor |
| Qué devuelve la cartera mediante OpenID4VP | El SD-JWT con un Key Binding JWT | Un DeviceResponse con una firma o un MAC sobre la transcripción de la sesión |
| Qué lo vincula a su solicitud | nonce y aud en el Key Binding JWT | El traspaso (handover) de OpenID4VP dentro de la transcripción de la sesión |
La vinculación al dispositivo es obligatoria para los PID en ambos formatos.[1][4]
En el caso de SD-JWT VC, la regla de OpenID4VP es estricta. Cuando require_cryptographic_holder_binding es true, el valor por defecto, la cartera "DEBE devolver un SD-JWT" con un Key Binding JWT. El claim nonce debe coincidir con el nonce de su solicitud, y aud debe coincidir con su Client Identifier, salvo a través de la Digital Credentials API, donde debe coincidir con su origen precedido de origin:.[4]
El device engagement es exclusivo de mdoc. En un flujo de proximidad, el usuario muestra un código QR o presenta una etiqueta NFC. Esta contiene lo que el lector necesita para abrir una conexión NFC, Bluetooth Low Energy o Wi-Fi Aware y establecer sobre ella un canal autenticado y cifrado, sin conexión a internet entre ambos.[1]
La cartera autentica al lector
Una presentación de proximidad con mdoc (ISO/IEC 18013-5), simplificada.[1]
Lo que ve el usuario:
Muestre su documento de identidad
Mostrar código QR
1El usuario abre la cartera e inicia una presentación.
Deje que el lector escanee
O toque el lector.
2Un código QR o un toque NFC establece el canal.
Elija qué compartir
- ApellidosCompartido
- Fecha de nacimientoCompartido
- Lugar de nacimientoNo compartido
Compartir
3La cartera identifica al lector y el usuario da su aprobación.
Compartido
4Solo los atributos aprobados salen del teléfono.[1]
Protocolos de presentación: OpenID4VP, ISO/IEC 18013-7 y proximidad
El ARF enumera lo que gestiona una cartera: ISO/IEC 18013-5 en proximidad, y OpenID4VP o ISO/IEC 18013-7 en remoto.[1]
| Protocolo | Dónde | SD-JWT VC | mdoc (ISO/IEC 18013-5) |
|---|---|---|---|
| ISO/IEC 18013-5 | Proximidad: QR o NFC, después NFC, Bluetooth Low Energy o Wi-Fi Aware | No | Sí |
| OpenID4VP con HAIP | Remoto: redirecciones y esquemas de URI personalizados, o la Digital Credentials API | Sí | Sí |
| ISO/IEC 18013-7 | Remoto: Anexo C sobre la Digital Credentials API; el esquema de URI personalizado del Anexo A es opcional para las carteras | No | Sí |
Qué protocolo transporta qué formato, según el ARF.[1]
Las atestaciones SD-JWT VC «no pueden utilizarse en presentaciones de proximidad». ISO/IEC 18013-7 «solo puede utilizarse para solicitar y presentar atestaciones en formato conforme con [ISO/IEC 18013-5]». OpenID4VP «solo es adecuado para flujos de transacciones de presentación remota» y transporta ambos formatos.[1] OpenID4VP 1.0 pasó a ser Especificación Final el 10 de julio de 2025.[5]
Vídeo pendiente: flow-eudi-openid4vp
Una presentación remota desde una cartera con OpenID4VP, de principio a fin.
El ARF no recomienda esquemas de URI personalizados entre dispositivos, porque esos flujos «son vulnerables a ataques de phishing y de retransmisión», y señala la Digital Credentials API como alternativa.[1] Esa API sigue siendo un borrador del W3C, y Chrome 141 la activa por defecto.[9][10] ISO indica que la especificación técnica de 2024 de 18013-7 está retirada y sustituida, con una tercera edición en desarrollo, así que compruebe qué edición utiliza su código.[7][8] Los detalles de la solicitud están en la guía del verificador OpenID4VP.
Qué exige el Reglamento de Ejecución (UE) 2026/1731 para el PID
La primera norma sobre formatos del PID, el Reglamento de Ejecución (UE) 2024/2977, establecía que el PID «se expedirá en dos formatos»: ISO/IEC 18013-5:2021 y el Verifiable Credentials Data Model 1.1.[2][3] El acto modificativo de julio de 2026 sustituyó esa frase. Ahora el PID «se expedirá de conformidad con las normas establecidas en el anexo II del Reglamento de Ejecución (UE) 2024/2979, cláusulas 5 (formato SD-JWT VC) y 6 (formato ISO/IEC-mdoc)».[2]
- 4 de diciembre de 2024Primera norma2024/2977: 18013-5 y VCDM 1.1.
- 22 de julio de 2026Modificación2026/1731: SD-JWT VC y mdoc.
- 23 de julio de 2026ARF v3.0.0Alineado con los actos modificativos.
- 24 de diciembre de 2026Plazo de las carterasUna cartera por Estado miembro.
- 11 de agosto de 2028RetratoEl requisito del retrato se aplica, salvo que el usuario renuncie expresamente, cuando proceda.
Cómo evolucionó la normativa sobre los formatos de PID.[1][2][3][6]
El mismo acto establece dos perfiles de presentación en su anexo al Reglamento de Ejecución (UE) 2024/2982: un «perfil ISO/IEC-mdoc» y un «perfil OpenID4VC-HAIP».[2]
- Envíe su certificado de registro: un elemento de
verifier_info«incluirá el certificado de registro».[2] - Utilice su certificado de acceso como certificado hoja con el prefijo de identificador de cliente
x509_hash.[2] - Siga el «Anexo C de ISO/IEC 18013-7:2025» para mdoc a través de la Digital Credentials API.[2]
El registro se trata en la guía para partes usuarias de la cartera EUDI, y el calendario en plazos de la cartera EUDI para 2026 y 2027.
SD-JWT VC frente a mdoc (ISO/IEC 18013-5): tabla comparativa
| Característica | SD-JWT VC | mdoc (ISO/IEC 18013-5) |
|---|---|---|
| Codificación | JSON Web Token | CBOR, binario |
| Divulgación selectiva | Hashes con sal | Hashes con sal |
| Caso de uso principal en el ARF | En remoto, por ejemplo identificación remota | Proximidad, por ejemplo un permiso de conducir móvil |
| Obligación de la cartera | Obligatorio | Obligatorio |
| PID emitido en este formato | Sí | Sí |
| Proximidad | No | Sí, ISO/IEC 18013-5 |
| En remoto | OpenID4VP con HAIP | OpenID4VP con HAIP, o ISO/IEC 18013-7 |
| Vinculación al dispositivo | Opcional en el formato, obligatoria para los PID | Obligatoria en el estándar |
| Identificador de formato en OpenID4VP | dc+sd-jwt | mso_mdoc |
| Ruta de las declaraciones | Claves JSON | Espacio de nombres y, después, identificador del elemento de datos |
Fuente: ARF, salvo la fila del PID (Reglamento de Ejecución 2026/1731) y las dos últimas filas (OpenID4VP 1.0).[1][2][4]
Los permisos de conducir móviles en Estados Unidos se basan en ISO/IEC 18013-5 para la proximidad.[7][8] La solución de verificación de edad de la UE fija la prueba de conocimiento cero como mecanismo de presentación obligatorio, "con la presentación mDoc simple como alternativa".[13] La EVO Wallet de Moldavia documenta OpenID4VP 1.0 con un mdoc ISO/IEC 18013-5, con el perfil de HAIP 1.0.[11]
Qué formato debe admitir una parte usuaria
Las unidades de cartera gestionan ambos formatos, y el PID se emite en los dos.[1][2] Los textos consultados para esta guía no contienen ninguna disposición que obligue a una parte usuaria a solicitar ambos. La lectura práctica es esta: un verificador remoto puede pedir cualquiera de los dos, y un lector sin conexión a internet necesita mdoc, el único formato que funciona en proximidad.[1]
1Enumere dónde interactúa con el usuario
Web, app, mostrador o acceso físico.
¿Alguno de ellos es un flujo de proximidad?
Implemente mdoc (ISO/IEC 18013-5)
También funciona en remoto.
Empiece por SD-JWT VC
JSON sobre OpenID4VP con HAIP.
2Mantenga la capa de consulta neutral respecto al formato
Una sola consulta DCQL puede indicar ambos formatos.
3Verifique emisor, revocación y vinculación
Las mismas comprobaciones se aplican a ambos.
El Digital Credentials Query Language (DCQL) de OpenID4VP permite que una misma solicitud incluya una consulta dc+sd-jwt y una consulta mso_mdoc en paralelo. La especificación muestra una solicitud de este tipo.[4] Según el ARF, la parte usuaria verifica la firma del emisor frente a un ancla de confianza de una Lista de Confianza o de una Lista de Entidades de Confianza, comprueba la revocación mediante una lista de estado o una lista de revocación y verifica la vinculación al dispositivo.[1]
Con eIDAS 2, Reglamento (UE) 2024/1183, cada Estado miembro debe ofrecer al menos una cartera antes del 24 de diciembre de 2026. Las partes usuarias privadas obligadas a utilizar la autenticación reforzada de usuario deben aceptarla a petición del usuario antes del 24 de diciembre de 2027. Las microempresas y pequeñas empresas están exentas de esta obligación de aceptación.[6] La situación de cada país figura en el seguimiento del lanzamiento de la cartera EUDI.
Bibliotecas y herramientas de prueba
Las fuentes de esta guía no citan ninguna biblioteca de código abierto, así que esta sección tampoco cita ninguna. Sí indican dónde hacer pruebas y qué comprobar en cualquier biblioteca que elija.
- Ejecute las pruebas de conformidad en conformance.eudi.dev, citadas en las notas de la versión ARF v3.0.0.[1]
- Lea la documentación de la implementación de referencia en docs.eudi.dev.[1]
- Estudie un verificador publicado: el Banco Nacional de Moldavia publicó un verificador de demostración con código fuente para entidades financieras.[12]
- Confirme que la biblioteca sigue HAIP, no solo las especificaciones de base.[1]
- Confirme qué edición de ISO/IEC 18013-7 implementa.[2][8]
Cómo le 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 utiliza hoy. Ya puede verificar a personas a distancia.
- Cinco eID nacionales funcionan hoy en Didit a través de carteras de identidad digital: MitID, BankID Suecia, Finnish Trust Network, Smart-ID y Mobile-ID. Consulte verificación de eID.
- Todos los demás usan la verificación de documentos con lectura del chip NFC, prueba de vida y comparación facial. Una comprobación KYC completa cuesta $0.33.
- El cribado AML se ejecuta en el mismo flujo por $0.20.
La documentación de carteras muestra cómo se activan las eID por país.
Didit aporta
- Los inicios de sesión con eID nacionales y la vía documental en un solo flujo de trabajo
- La evidencia de cada comprobación
Queda a su cargo
- Su registro como parte usuaria de la cartera
- La elección de los formatos y atributos que solicita
- La decisión de alta y sus políticas
Planifique con nosotros los formatos de cartera
Indíquenos sus países y dónde se encuentra con sus usuarios, y empiece hoy con eID nacionales y documentos.
Puntos clave
- Las carteras admiten tanto SD-JWT VC como mdoc (ISO/IEC 18013-5), y el PID se expide en ambos.
- Ambos usan hashes con sal para la divulgación selectiva; difieren en la codificación: JSON frente a CBOR.
- SD-JWT VC solo funciona en remoto. mdoc funciona en proximidad y en remoto.
- OpenID4VP con HAIP transporta ambos formatos, de modo que un mismo verificador puede solicitar cualquiera de los dos.
Preguntas frecuentes
¿Qué es un SD-JWT VC?
Una credencial verificable empaquetada como Selectively Disclosable JSON Web Token. El emisor firma resúmenes de las declaraciones y la cartera revela solo las declaraciones que el usuario aprueba.[1]
¿Qué es un mdoc según la norma ISO/IEC 18013-5?
Un documento móvil en formato CBOR, definido inicialmente para los permisos de conducción móviles. El resto de la norma es genérico y puede contener otras atestaciones, incluidos los PID.[1]
¿Qué diferencia hay entre SD-JWT VC y mdoc?
La codificación y el alcance. SD-JWT VC usa JSON y solo funciona en remoto; mdoc usa CBOR y también funciona en proximidad. Ambos usan hashes con sal para la divulgación selectiva.[1]
¿Qué formatos usa el PID de la cartera europea de identidad digital (EUDI Wallet)?
Ambos. El Reglamento de Ejecución (UE) 2026/1731 establece que el PID se expide en formato SD-JWT VC y en formato ISO/IEC-mdoc.[2]
¿Tiene una parte usuaria que admitir ambos formatos?
Los textos consultados para esta guía obligan a las carteras a gestionar ambos y no dicen que una parte usuaria deba solicitar ambos. Un verificador remoto puede pedir cualquiera de los dos. Un lector de proximidad necesita mdoc.[1][2]
¿Cómo funciona la divulgación selectiva en SD-JWT VC?
El token firmado contiene resúmenes en lugar de los valores de las declaraciones. Cada declaración viaja como una divulgación con un valor aleatorio, el nombre y el valor. El verificador calcula su hash y busca el resumen.[4]
¿Qué es la vinculación de clave y es lo mismo que la autenticación mdoc?
Ambos son nombres de la vinculación al dispositivo, la prueba de que la credencial pertenece a claves de la cartera del usuario. Es obligatoria para los PID.[1]
¿Funciona OpenID4VP con mdoc?
Sí. OpenID4VP transporta ambos formatos, con el identificador mso_mdoc para mdoc y dc+sd-jwt para SD-JWT VC. ISO/IEC 18013-7 es la otra opción remota y solo transporta mdoc.[1][4]
¿Dónde puedo probar un verificador para ambos formatos?
Use las pruebas de conformidad de conformance.eudi.dev y la documentación de docs.eudi.dev. El Banco Nacional de Moldavia también publicó un verificador de demostración con su código fuente.[1][12]
Fuentes
- Architecture and Reference Framework v3.0.0, eu-digital-identity-wallet en GitHub, versión publicada el 23 de julio de 2026.
- 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) 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.
- OpenID for Verifiable Presentations 1.0, OpenID Foundation, especificación final.
- OpenID for Verifiable Presentations 1.0 Final Specification Approved, OpenID Foundation, 10 de julio de 2025.
- Reglamento (UE) 2024/1183 (eIDAS 2), EUR-Lex, Diario Oficial de 30 de abril de 2024.
- Serie ISO/IEC 18013, permiso de conducción móvil, página de la norma en ISO.
- ISO/IEC 18013-7, página de la norma en ISO.
- Digital Credentials, borrador del W3C.
- Digital Credentials API shipped, Chrome for Developers.
- Guía para desarrolladores de EVO Wallet, Gobierno de Moldavia, egov4dev.
- Verificador de demostración del BNM, Gobierno de Moldavia, egov4dev.
- Solución de verificación de edad de la UE, portal técnico, ageverification.dev.
SD-JWT VC y mdoc (ISO/IEC 18013-5) son dos codificaciones de la misma promesa: atributos firmados que controla el usuario. Consulte cómo aborda Didit la aceptación de carteras en la página de la solución de cartera EUDI, y todos los sistemas nacionales en sistemas de eID por país.
Verifique a personas a distancia mientras se despliegan las carteras
Utilice ya las eID nacionales y la vía documental, y hable con nosotros sobre la cartera EUDI.
Artículos relacionados
- e-Devlet para empresas: verificación de identidad en Turquía
- Integración de Singpass Myinfo: guía para empresas en Singapur
- 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)