DCQL expliqué : comment un vérificateur demande à un wallet exactement ce dont il a besoin
DCQL, le Digital Credentials Query Language, est la façon convenue pour une organisation d'indiquer à un portefeuille quelles attestations elle demande et quelles données à l'intérieur. C'est ce qui transforme une demande telle que « prouvez que votre entreprise est immatriculée aux Pays-Bas » en quelque chose que tout portefeuille conforme comprend, sans intégration distincte par portefeuille.
Le problème que résout DCQL
Un business wallet contient des attestations de toutes sortes, émises par des organismes différents dans des pays différents et enregistrées dans des formats techniques différents. Une organisation qui doit seulement confirmer un numéro d'immatriculation et une dénomination sociale n'a aucun moyen portable de demander exactement cela. Elle finit soit par prendre l'attestation entière, avec tout ce qu'elle contient, soit par construire une intégration distincte pour chaque portefeuille rencontré.
DCQL règle le côté de la demande. Une demande standard nomme les attestations souhaitées et les données précises attendues de chacune. Le portefeuille compare cela à ce que le titulaire possède réellement, montre au titulaire ce qui est demandé, et ne divulgue que cela. Le vérificateur obtient une réponse prévisible quel que soit le portefeuille utilisé par le titulaire.
1. Vérificateur
Demande exactement les attestations et les données dont il a besoin
2. Wallet
Détermine lesquelles des attestations enregistrées correspondent à la demande
3. Titulaire
Voit ce qui est demandé et approuve la divulgation de cela seulement
4. Vérificateur
Reçoit les données approuvées, et rien de plus
Ce qu'un vérificateur peut demander
Une demande est une courte liste de ce qui est nécessaire. Elle peut nommer une attestation ou plusieurs, et pour chacune elle peut nommer les données précises attendues plutôt que l'ensemble. Trois options supplémentaires couvrent presque tous les cas réels : les solutions de repli, les combinaisons et une limite sur les émetteurs acceptables.
- Quelles attestations sont nécessaires, et quelles données à l'intérieur de chacune.
- Des solutions de repli acceptables, par ordre de préférence, pour les titulaires qui n'ont pas tout.
- Les combinaisons, pour qu'une demande puisse exiger une attestation et en accepter une parmi deux autres.
- Une restriction aux émetteurs figurant sur une trusted list officielle, pour que les attestations des autres ne soient jamais proposées.
Demander une solution de repli
Tous les titulaires ne portent pas la même attestation. Un vérificateur peut indiquer ce qu'il préfère et ce qu'il accepte encore, dans l'ordre, et le portefeuille utilise la meilleure option que le titulaire peut réellement fournir. Cela évite un second échange et évite d'écarter un client à qui il ne manque que le détail le plus confortable.
1. Préféré
Utilisé lorsque l'attestation contient les deux
2. Solution de repli
Utilisé uniquement lorsque la première option ne peut pas être satisfaite
Ici, le vérificateur préfère un numéro d'immatriculation accompagné de la dénomination sociale, mais il accepte la dénomination sociale seule lorsque l'attestation du titulaire ne contient pas de numéro d'immatriculation.
Combiner des attestations dans une seule demande
Les contrôles d'entrée en relation reposent rarement sur un seul document. Un vérificateur peut exiger une attestation et en accepter une parmi deux autres à côté, le tout dans une seule demande, si bien que le titulaire approuve une fois et que le vérificateur obtient une réponse complète en une étape.
Obligatoire
Immatriculation
L’un de
Numéro de TVA
L’un de
Attestation bancaire
Une immatriculation de l'entreprise est obligatoire. En plus de cela, une immatriculation à la TVA ou une attestation de compte bancaire suffit, et le titulaire n'a besoin que de l'une des deux.
N'accepter que des émetteurs de confiance
Un vérificateur peut restreindre une demande aux attestations dont l'émetteur figure sur une trusted list officielle. Les attestations des autres ne sont même jamais proposées au titulaire, de sorte qu'une imitation auto-émise n'atteint pas le contrôle.
Le vérificateur dit : uniquement des émetteurs figurant sur une trusted list officielle de l'UE
Attestation d’immatriculation d’un émetteur listé
L'émetteur figure sur la trusted list
✓ Proposé au titulaire
Attestation d’immatriculation d’un émetteur non listé
L'émetteur ne figure pas sur la trusted list
✗ Non proposé au titulaire
Il s'agit d'un filtre dans le portefeuille, pas d'une garantie en soi. Le vérificateur contrôle toujours l'émetteur par rapport à la trusted list lorsqu'il valide ce qu'il a reçu.
Où en est DCQL aujourd’hui
- DCQL fait partie de la spécification OpenID4VP elle-même plutôt que d'un document distinct, et il a remplacé une dépendance antérieure à DIF Presentation Exchange.
- L'EUDI Wallet Architecture and Reference Framework cite OpenID4VP comme protocole de présentation et DCQL avec lui, les portefeuilles et vérificateurs de l'écosystème sont donc censés le prendre en charge.
- Les portefeuilles et vérificateurs de référence du programme EUDI Wallet ont convergé vers DCQL, une intégration business wallet lancée aujourd'hui devrait donc le retenir plutôt que l'ancienne solution.
Ce que cela signifie pour vous
Vérificateur
Un seul format de demande couvre tous les portefeuilles, et vous ne recevez que les données demandées, donc moins de données à stocker, à sécuriser et à justifier.
Titulaire
Vous voyez exactement ce qui est demandé avant d'approuver, et rien au-delà ne quitte votre portefeuille.
Émetteur
Les attestations que vous émettez restent utiles pour des contrôles partiels, si bien qu'une seule attestation peut servir à de nombreuses fins différentes.
Approfondissement technique
Cette page explique ce que fait la technologie et qui elle concerne. Notre documentation pour développeurs couvre la mise en œuvre elle-même : les messages, les champs et les exemples détaillés dont une équipe d'intégration a besoin.
Lire la documentation techniqueTermes associés
Questions fréquentes
En quoi DCQL diffère-t-il de DIF Presentation Exchange ?
Les deux permettent à un vérificateur de décrire ce qu'il attend d'un portefeuille. Presentation Exchange est le plus ancien et le plus large des deux, conçu pour fonctionner avec plusieurs protocoles. DCQL est délibérément plus réduit et est défini dans OpenID4VP même. L'écosystème EUDI Wallet a retenu DCQL, c'est donc sur lui qu'il faut compter pour le marché européen.
Une seule demande peut-elle porter sur plusieurs attestations ?
Oui, et c'est l'une des raisons de son existence. Un vérificateur peut demander une immatriculation de l'entreprise et une attestation de compte bancaire dans une seule demande, ou accepter l'une de deux alternatives, et le titulaire approuve le tout en une étape au lieu d'être sollicité deux fois.
Que se passe-t-il si le titulaire n'a pas tout ce qui a été demandé ?
Le vérificateur peut nommer des solutions de repli acceptables, par ordre de préférence, et le portefeuille utilise la meilleure que le titulaire peut réellement fournir. Un vérificateur peut ainsi demander un numéro d'immatriculation précis là où il existe et se contenter de la dénomination sociale là où il n'existe pas, sans envoyer une seconde demande ni écarter le titulaire.
DCQL est-il propre à l’EUDI Wallet ?
Non. DCQL fait partie d'OpenID4VP et toute implémentation de ce protocole peut l'utiliser. L'écosystème EUDI Wallet en est un adoptant majeur : l'Architecture and Reference Framework cite OpenID4VP avec DCQL comme la façon de présenter des attestations, ce qui le rend important pour quiconque construit pour le marché européen.
Est-ce que cela aide pour la minimisation des données au titre du GDPR ?
Cela rend le minimum explicite. La demande indique quelles données sont nécessaires, le titulaire voit cette liste avant d'approuver, et le portefeuille ne divulgue rien au-delà. La minimisation des données cesse d'être une promesse inscrite dans une politique pour devenir une limite imposée par l'échange lui-même, ce qui est bien plus facile à démontrer.
Sources
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.