DCQL expliqué : comment un vérificateur demande à un wallet exactement ce dont il a besoin

Le problème que résout DCQL

Prévoir une solution de repli : claim_sets

claim_sets liste des groupes d’ids de claims par ordre de préférence. Le wallet renvoie le premier groupe qu’il peut satisfaire entièrement avec ce que le titulaire détient réellement, ce qui évite au vérificateur d’envoyer deux requêtes distinctes pour le cas précis et le cas de repli.

{
  "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"]
      ]
    }
  ]
}

Ici, le vérificateur préfère un numéro d’immatriculation et la dénomination sociale, mais accepte la dénomination sociale seule si l’attestation du titulaire ne contient pas de claim de numéro d’immatriculation.

{
  "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."
}

Combiner des attestations : credential_sets

credential_sets agit un niveau au-dessus de claim_sets. Chaque entrée liste des options, chaque option étant un groupe d’ids de requêtes d’attestation. Le wallet doit satisfaire une option de chaque entrée obligatoire, ce qui offre au vérificateur une logique ET et OU entre attestations dans une seule requête.

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

Exemple de réponse : immatriculation et compte bancaire

Ce que le wallet envoie

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

Claims visibles par le vérificateur après validation

{
  "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."
  }
}

Le titulaire ne possède pas d’attestation de numéro de TVA : le wallet a donc choisi la seconde option du second ensemble. Les ids de requête non utilisés, ici vat_registration, sont simplement absents de vp_token.

Uniquement des émetteurs de confiance : trusted_authorities

trusted_authorities restreint une requête d’attestation aux attestations dont l’émetteur est garanti par une autorité à laquelle le vérificateur fait confiance. Chaque entrée comporte un type et une liste de values : aki pour un authority key identifier, etsi_tl pour une ETSI trusted list, ou openid_federation pour un trust anchor de fédération. Le wallet ne propose que les attestations correspondantes.

Exemple détaillé : une immatriculation issue d’un émetteur listé

{
  "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"] }
      ]
    }
  ]
}

Exemple de réponse : seule l’attestation de l’émetteur listé

Ce que le wallet envoie

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

Claims visibles par le vérificateur après validation

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

Le titulaire possédait aussi une attestation d’immatriculation d’un émetteur non listé, mais le wallet ne l’a pas proposée. trusted_authorities est un filtre pour le wallet, pas une garantie : le vérificateur contrôle lui-même l’émetteur par rapport à la liste de confiance lors de la validation de la présentation.

Correspondance de valeur : claims.values

Une requête de claim peut contenir values, une liste de chaînes, d’entiers ou de booléens. Le wallet ne renvoie le claim que si son type et sa valeur correspondent exactement à l’un d’eux. Un vérificateur peut ainsi contrôler une condition sans rien demander d’autre au préalable.

Exemple détaillé : uniquement des entreprises immatriculées aux Pays-Bas ou en Belgique

{
  "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"]
        }
      ]
    }
  ]
}

Exemple de réponse : une entreprise néerlandaise

Ce que le wallet envoie

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

Claims visibles par le vérificateur après validation

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

L’attestation d’une entreprise allemande a registration_country "DE" : elle ne satisfait donc pas la requête et le wallet n’a rien à renvoyer pour elle. Le vérificateur doit néanmoins contrôler la valeur dans les claims validés plutôt que de se fier au filtrage du wallet.

Où en est DCQL aujourd’hui

• DCQL est défini au sein même de la spécification OpenID4VP, et non dans un document distinct. Il fait partie du brouillon depuis l’introduction du mécanisme destiné à remplacer une dépendance antérieure à DIF Presentation Exchange pour les requêtes OpenID4VP.
• L’EUDI Wallet Architecture and Reference Framework désigne OpenID4VP comme protocole de présentation et, par conséquent, DCQL comme mécanisme de requête que les parties utilisatrices et les wallets de l’écosystème sont censés prendre en charge.
• Les implémentations de référence de wallets et de vérificateurs du programme EUDI Wallet Reference Implementation ont convergé vers DCQL. Les nouvelles intégrations de business wallets construites aujourd’hui sur OpenID4VP doivent donc partir du principe que DCQL, et non Presentation Exchange, est le format de requête des demandes de présentation.

Questions fréquentes

Cette page est fournie à titre informatif et ne constitue pas un avis juridique. Pour des informations faisant autorité, consultez directement l’OpenID Foundation et la Commission européenne.