DCQL explicado: cómo un verificador pide a una wallet exactamente lo que necesita
DCQL, el Digital Credentials Query Language, es la forma acordada de que una organización indique a una cartera qué credenciales necesita y qué datos dentro de ellas. Es lo que convierte una solicitud como "demuestre que su empresa está registrada en los Países Bajos" en algo que toda cartera conforme entiende, sin una integración distinta por cartera.
El problema que resuelve DCQL
Un business wallet contiene credenciales de muchos tipos, emitidas por organismos distintos en países distintos y guardadas en formatos técnicos distintos. Una organización que solo necesita confirmar un número de registro y una denominación social no tiene forma portable de pedir exactamente eso. Acaba tomando la credencial entera, con todo lo que contiene, o construyendo una integración distinta para cada cartera con la que se encuentra.
DCQL resuelve el lado de la pregunta. Una solicitud estándar nombra las credenciales que se quieren y los datos concretos que se necesitan de cada una. La cartera lo contrasta con lo que el titular tiene realmente, le muestra qué se le pide, y entrega solo eso. El verificador obtiene una respuesta previsible con independencia de la cartera que use el titular.
1. Verificador
Pide exactamente las credenciales y los datos que necesita
2. Wallet
Determina cuáles de las credenciales guardadas encajan con la solicitud
3. Titular
Ve qué se pide y aprueba entregar solo eso
4. Verificador
Recibe los datos aprobados, y nada más
Qué puede pedir un verificador
Una solicitud es una lista breve de lo que se necesita. Puede nombrar una credencial o varias, y de cada una puede nombrar los datos concretos que se quieren en lugar del conjunto. Tres opciones adicionales cubren casi todos los casos reales: alternativas de respaldo, combinaciones y un límite sobre qué emisores resultan aceptables.
- Qué credenciales se necesitan, y qué datos dentro de cada una.
- Alternativas de respaldo aceptables, por orden de preferencia, para titulares que no lo tienen todo.
- Combinaciones, para que una solicitud pueda exigir una credencial y aceptar cualquiera de otras dos.
- Una restricción a emisores que figuren en una trusted list oficial, para que las credenciales de cualquier otro nunca se ofrezcan.
Pedir una alternativa de respaldo
No todos los titulares llevan la misma credencial. Un verificador puede indicar qué prefiere y qué aceptaría también, por orden, y la cartera usa la mejor opción que el titular puede satisfacer realmente. Eso evita una segunda ronda y evita rechazar a un cliente al que solo le falta el detalle más cómodo de tener.
1. Preferido
Se usa cuando la credencial contiene ambos datos
2. Alternativa
Se usa solo cuando la primera opción no puede cumplirse
Aquí el verificador prefiere un número de registro junto con la denominación social, pero acepta la denominación social por sí sola cuando la credencial del titular no incluye un número de registro.
Combinar credenciales en una sola solicitud
Las comprobaciones de alta rara vez se apoyan en un único documento. Un verificador puede exigir una credencial y aceptar junto a ella cualquiera de otras dos, todo en una sola solicitud, de modo que el titular aprueba una vez y el verificador obtiene una respuesta completa en un solo paso.
Obligatorio
Registro mercantil
Uno de
Registro de IVA
Uno de
Certificado de cuenta bancaria
La inscripción mercantil de la empresa es obligatoria. Además de eso, basta con el alta en el IVA o un certificado de cuenta bancaria, y el titular solo necesita tener uno de los dos.
Aceptar solo emisores de confianza
Un verificador puede limitar una solicitud a credenciales cuyo emisor figure en una trusted list oficial. Las credenciales de cualquier otro ni siquiera se ofrecen al titular, de modo que una imitación autoemitida no llega a alcanzar la comprobación.
El verificador dice: solo de emisores que figuren en una trusted list oficial de la UE
Credencial de registro de un emisor incluido
El emisor figura en la trusted list
✓ Se ofrece al titular
Credencial de registro de un emisor no incluido
El emisor no figura en la trusted list
✗ No se ofrece al titular
Esto es un filtro en la cartera, no una garantía por sí mismo. El verificador sigue contrastando al emisor con la trusted list cuando valida lo que ha recibido.
Situación actual de DCQL
- DCQL forma parte de la propia especificación OpenID4VP en lugar de ser un documento aparte, y sustituyó a una dependencia anterior de DIF Presentation Exchange.
- El EUDI Wallet Architecture and Reference Framework señala OpenID4VP como protocolo de presentación y DCQL junto a él, así que se espera que las carteras y los verificadores del ecosistema lo admitan.
- Las carteras y verificadores de referencia del programa EUDI Wallet han convergido en DCQL, así que una integración de business wallet que empiece hoy debería asumirlo en lugar de la alternativa anterior.
Qué significa esto para usted
Verificador
Un único formato de solicitud sirve para todas las carteras, y solo recibe los datos que pidió, lo que supone menos datos que almacenar, proteger y justificar.
Titular
Usted ve exactamente qué se pide antes de aprobar, y nada más allá de eso sale de su cartera.
Emisor
Las credenciales que emite siguen siendo útiles para comprobaciones parciales, de modo que una sola credencial puede servir a muchos fines distintos.
Profundización técnica
Esta página explica qué hace la tecnología y a quién afecta. Nuestra documentación para desarrolladores cubre la implementación en sí: los mensajes, los campos y los ejemplos resueltos que necesita un equipo de integración.
Leer la documentación técnicaTérminos relacionados
Preguntas frecuentes
¿En qué se diferencia DCQL de DIF Presentation Exchange?
Ambas son maneras de que un verificador describa lo que quiere de una cartera. Presentation Exchange es la más antigua y amplia de las dos, diseñada para funcionar con varios protocolos. DCQL es deliberadamente menor y está definida dentro del propio OpenID4VP. El ecosistema EUDI Wallet se ha estandarizado en DCQL, así que es la opción con la que planificar para el mercado europeo.
¿Puede una sola solicitud pedir más de una credencial?
Sí, y esa es una de las razones de su existencia. Un verificador puede pedir una inscripción mercantil y un certificado de cuenta bancaria en una sola solicitud, o aceptar cualquiera de dos alternativas, y el titular lo aprueba todo en un paso en lugar de que se le pregunte dos veces.
¿Qué ocurre si el titular no tiene todo lo que se le ha pedido?
El verificador puede nombrar alternativas de respaldo aceptables, por orden de preferencia, y la cartera usa la mejor que el titular puede satisfacer realmente. Así, un verificador puede pedir un número de registro exacto donde exista y conformarse con la denominación social donde no exista, sin enviar una segunda solicitud ni rechazar al titular.
¿DCQL es exclusivo de la EUDI Wallet?
No. DCQL forma parte de OpenID4VP y cualquier implementación de ese protocolo puede usarlo. El ecosistema EUDI Wallet es un adoptante destacado: el Architecture and Reference Framework señala OpenID4VP con DCQL como la forma de presentar credenciales, y por eso importa a cualquiera que construya para el mercado europeo.
¿Ayuda esto con la minimización de datos conforme al GDPR?
Hace explícito el mínimo. La solicitud indica qué datos se necesitan, el titular ve esa lista antes de aprobar, y la cartera no entrega nada más allá. Eso convierte la minimización de datos de una promesa en una política a un límite que el propio intercambio impone, algo mucho más fácil de demostrar.
Fuentes
Esta página es informativa y no constituye asesoramiento jurídico. Para obtener información autorizada, consulte directamente a la OpenID Foundation y a la Comisión Europea.