DCQL explicado: cómo un verificador pide a una wallet exactamente lo que necesita

El problema que resuelve DCQL

Pedir una alternativa: claim_sets

claim_sets enumera grupos de ids de claims por orden de preferencia. La wallet devuelve el primer grupo que puede satisfacer por completo con lo que el titular tiene realmente, en lugar de que el verificador tenga que enviar dos solicitudes distintas para el caso preciso y el alternativo.

{
  "credentials": [
    {
      "id": "company_registration",
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["urn:eudi:business:company-registration:1"] },
      "claims": [
        { "id": "reg_no", "path": ["registration_number"] },
        { "id": "legal_name", "path": ["legal_name"] }
      ],
      "claim_sets": [
        ["reg_no", "legal_name"],
        ["legal_name"]
      ]
    }
  ]
}

Aquí el verificador prefiere un número de registro más la razón social, pero acepta solo la razón social si la credencial del titular no incluye un claim de número de registro.

{
  "vp_token": {
    "company_registration": [
      "<issuer-signed JWT>~<disclosure: legal_name>~<key binding JWT>"
    ]
  }
}

{
  "vct": "urn:eudi:business:company-registration:1",
  "legal_name": "Example Logistics B.V."
}

Combinar credenciales: credential_sets

credential_sets funciona un nivel por encima de claim_sets. Cada entrada enumera options, donde cada opción es un grupo de ids de consultas de credenciales. La wallet debe satisfacer una opción de cada entrada obligatoria, lo que da al verificador lógica Y y O entre credenciales en una sola solicitud.

"credential_sets": [
  { "options": [["company_registration"]] },
  { "options": [["vat_registration"], ["bank_account"]] }
]

Ejemplo de respuesta: registro más cuenta bancaria

Lo que envía la wallet

{
  "vp_token": {
    "company_registration": [
      "<issuer-signed JWT>~<disclosures>~<key binding JWT>"
    ],
    "bank_account": [
      "<issuer-signed JWT>~<disclosures>~<key binding JWT>"
    ]
  }
}

Claims que ve el verificador tras la validación

{
  "company_registration": {
    "vct": "urn:eudi:business:company-registration:1",
    "registration_number": "12345678",
    "legal_name": "Example Logistics B.V."
  },
  "bank_account": {
    "vct": "urn:eudi:business:bank-account:1",
    "iban": "NL91ABNA0417164300",
    "account_holder": "Example Logistics B.V."
  }
}

El titular no tiene una credencial de registro de IVA, así que la wallet eligió la segunda opción del segundo conjunto. Los ids de consulta que no se usaron, en este caso vat_registration, simplemente no aparecen en vp_token.

Solo emisores de confianza: trusted_authorities

trusted_authorities limita una consulta de credencial a credenciales cuyo emisor está respaldado por una autoridad en la que confía el verificador. Cada entrada tiene un type y una lista de values: aki para un authority key identifier, etsi_tl para una ETSI trusted list u openid_federation para un trust anchor de federación. La wallet solo ofrece las credenciales que coinciden.

Ejemplo práctico: un registro de un emisor incluido en la lista

{
  "credentials": [
    {
      "id": "company_registration",
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["urn:eudi:business:company-registration:1"] },
      "trusted_authorities": [
        {
          "type": "etsi_tl",
          "values": ["https://ec.europa.eu/tools/lotl/eu-lotl.xml"]
        }
      ],
      "claims": [
        { "id": "reg_no", "path": ["registration_number"] },
        { "id": "legal_name", "path": ["legal_name"] }
      ]
    }
  ]
}

Ejemplo de respuesta: solo la credencial del emisor incluido

Lo que envía la wallet

{
  "vp_token": {
    "company_registration": [
      "<issuer-signed JWT>~<disclosure: registration_number>~<disclosure: legal_name>~<key binding JWT>"
    ]
  }
}

Claims que ve el verificador tras la validación

{
  "vct": "urn:eudi:business:company-registration:1",
  "registration_number": "12345678",
  "legal_name": "Example Logistics B.V."
}

El titular también tenía una credencial de registro de un emisor no incluido, pero la wallet no la ofreció. trusted_authorities es un filtro para la wallet, no una garantía: el verificador sigue comprobando por su cuenta al emisor frente a la lista de confianza al validar la presentación.

Coincidencia de valores: claims.values

Una consulta de claim puede incluir values, una lista de cadenas, enteros o booleanos. La wallet solo devuelve el claim cuando su tipo y su valor coinciden exactamente con uno de ellos, de modo que un verificador puede comprobar una condición sin pedir antes ningún otro dato.

Ejemplo práctico: solo empresas registradas en los Países Bajos o Bélgica

{
  "credentials": [
    {
      "id": "company_registration",
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["urn:eudi:business:company-registration:1"] },
      "claims": [
        { "id": "legal_name", "path": ["legal_name"] },
        {
          "id": "reg_country",
          "path": ["registration_country"],
          "values": ["NL", "BE"]
        }
      ]
    }
  ]
}

Ejemplo de respuesta: una empresa neerlandesa

Lo que envía la wallet

{
  "vp_token": {
    "company_registration": [
      "<issuer-signed JWT>~<disclosure: legal_name>~<disclosure: registration_country>~<key binding JWT>"
    ]
  }
}

Claims que ve el verificador tras la validación

{
  "vct": "urn:eudi:business:company-registration:1",
  "legal_name": "Example Logistics B.V.",
  "registration_country": "NL"
}

La credencial de una empresa alemana tiene registration_country "DE", así que no satisface la consulta y la wallet no tiene nada que devolver para ella. Aun así, el verificador debe comprobar el valor en los claims validados en lugar de confiar en el filtrado de la wallet.

Situación actual de DCQL

• DCQL está definido dentro de la propia especificación OpenID4VP, no como documento aparte, y forma parte del borrador desde que se introdujo el mecanismo para sustituir una dependencia anterior de DIF Presentation Exchange en las solicitudes OpenID4VP.
• El EUDI Wallet Architecture and Reference Framework establece OpenID4VP como protocolo de presentación y, con él, DCQL como el mecanismo de consulta que deben admitir las partes usuarias y las wallets del ecosistema.
• Las implementaciones de referencia de wallets y verificadores del programa EUDI Wallet Reference Implementation han convergido en DCQL, por lo que las nuevas integraciones de business wallets basadas hoy en OpenID4VP deberían dar por hecho DCQL, y no Presentation Exchange, como formato de consulta para las solicitudes de presentación.

Preguntas frecuentes

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.