DCQL uitgelegd: hoe een verifier een wallet om precies de juiste gegevens vraagt
DCQL, de Digital Credentials Query Language, is de afgesproken manier waarop een organisatie een wallet vertelt welke credentials zij nodig heeft en welke gegevens daarbinnen. Het maakt van een verzoek als "bewijs dat uw bedrijf in Nederland is ingeschreven" iets dat elke conforme wallet begrijpt, zonder een aparte integratie per wallet.
Het probleem dat DCQL oplost
Een business wallet bevat credentials van allerlei soorten, uitgegeven door verschillende instanties in verschillende landen en opgeslagen in verschillende technische formaten. Een organisatie die alleen een registratienummer en een statutaire naam hoeft te bevestigen, heeft geen overdraagbare manier om precies daarom te vragen. Zij neemt dan ofwel de hele credential over, met alles wat daarin staat, ofwel bouwt zij een aparte integratie voor elke wallet die zij tegenkomt.
DCQL lost de vraagkant op. Eén standaardverzoek benoemt de gewenste credentials en de specifieke gegevens die uit elk daarvan nodig zijn. De wallet toetst dat aan wat de houder werkelijk heeft, laat de houder zien wat er gevraagd wordt, en geeft alleen dat vrij. De verifier krijgt een voorspelbaar antwoord, ongeacht welke wallet de houder gebruikt.
1. Verifier
Vraagt precies om de credentials en gegevens die nodig zijn
2. Wallet
Bepaalt welke van de opgeslagen credentials bij het verzoek passen
3. Houder
Ziet wat er gevraagd wordt en keurt goed dat alleen dat wordt vrijgegeven
4. Verifier
Ontvangt de goedgekeurde gegevens, en niets meer
Waar een verifier om kan vragen
Een verzoek is een korte lijst van wat er nodig is. Het kan één credential of meerdere benoemen, en per credential kan het de specifieke gewenste gegevens benoemen in plaats van het geheel. Drie opties daarbovenop dekken vrijwel elk praktijkgeval: terugvalopties, combinaties en een beperking op welke uitgevers aanvaardbaar zijn.
- Welke credentials nodig zijn, en welke gegevens binnen elk daarvan.
- Aanvaardbare terugvalopties, in volgorde van voorkeur, voor houders die niet alles hebben.
- Combinaties, zodat een verzoek één credential kan verplichten en daarnaast een van twee andere.
- Een beperking tot uitgevers op een officiële trusted list, zodat credentials van anderen nooit worden aangeboden.
Vragen om een terugvaloptie
Niet elke houder heeft dezelfde credential op zak. Een verifier kan benoemen wat hij het liefst krijgt en wat hij ook nog accepteert, in volgorde, en de wallet gebruikt de beste optie die de houder daadwerkelijk kan bieden. Dat scheelt een tweede ronde en voorkomt dat u een klant wegstuurt die alleen het mooiste detail mist.
1. Voorkeur
Gebruikt wanneer de credential beide bevat
2. Terugval
Alleen gebruikt wanneer de eerste optie niet haalbaar is
Hier krijgt de verifier het liefst een registratienummer samen met de statutaire naam, maar accepteert hij de statutaire naam op zichzelf wanneer de credential van de houder geen registratienummer bevat.
Credentials combineren in één verzoek
Onboardingcontroles steunen zelden op één document. Een verifier kan één credential verplicht stellen en daarnaast een van twee andere accepteren, allemaal in één verzoek, zodat de houder één keer goedkeurt en de verifier in één stap een volledig antwoord krijgt.
Verplicht
Bedrijfsregistratie
Eén van
Btw-registratie
Eén van
Bankrekeningattestatie
Een inschrijving in het handelsregister is verplicht. Daarbovenop volstaat een btw-registratie of een attestatie van een bankrekening, en de houder hoeft er maar één van te hebben.
Alleen vertrouwde uitgevers accepteren
Een verifier kan een verzoek beperken tot credentials waarvan de uitgever op een officiële trusted list staat. Credentials van anderen worden de houder zelfs nooit aangeboden, zodat een zelf uitgegeven kopie de controle niet eens bereikt.
De verifier zegt: alleen van uitgevers op een officiële EU trusted list
Registratiecredential van een vermelde issuer
De uitgever staat op de trusted list
✓ Aangeboden aan de houder
Registratiecredential van een niet-vermelde issuer
De uitgever staat niet op de trusted list
✗ Niet aangeboden aan de houder
Dit is een filter in de wallet, geen garantie op zichzelf. De verifier controleert de uitgever nog steeds tegen de trusted list wanneer hij valideert wat hij heeft ontvangen.
Waar DCQL nu staat
- DCQL maakt deel uit van de OpenID4VP-specificatie zelf in plaats van een apart document, en het verving een eerdere afhankelijkheid van DIF Presentation Exchange.
- Het EUDI Wallet Architecture and Reference Framework noemt OpenID4VP als het presentatieprotocol en DCQL daarbij, dus van wallets en verifiers in het ecosysteem wordt verwacht dat zij het ondersteunen.
- De referentiewallets en verifiers in het EUDI Wallet-programma zijn op DCQL uitgekomen, dus een business wallet-integratie die vandaag begint, kan daarvan uitgaan en niet van het oudere alternatief.
Wat dit voor u betekent
Verifier
Eén verzoekformaat werkt voor elke wallet, en u ontvangt alleen de gegevens waar u om vroeg, wat minder data betekent om op te slaan, te beveiligen en te verantwoorden.
Houder
U ziet precies wat er gevraagd wordt voordat u goedkeurt, en niets daarbuiten verlaat uw wallet.
Uitgever
Credentials die u uitgeeft blijven bruikbaar voor gedeeltelijke controles, zodat één credential veel verschillende doelen kan dienen.
Technische verdieping
Deze pagina legt uit wat de technologie doet en wie ermee te maken krijgt. Onze ontwikkelaarsdocumentatie behandelt de implementatie zelf: de berichten, de velden en de uitgewerkte voorbeelden die een integratieteam nodig heeft.
Lees de technische documentatieGerelateerde begrippen
Veelgestelde vragen
Wat is het verschil tussen DCQL en DIF Presentation Exchange?
Beide zijn manieren waarop een verifier beschrijft wat hij van een wallet wil. Presentation Exchange is de oudere en bredere van de twee, ontworpen om met meerdere protocollen te werken. DCQL is bewust kleiner en is binnen OpenID4VP zelf gedefinieerd. Het EUDI Wallet-ecosysteem heeft DCQL als standaard gekozen, dus daar plant u voor de Europese markt omheen.
Kan één verzoek om meer dan één credential vragen?
Ja, en dat is een van de redenen dat het bestaat. Een verifier kan in één verzoek vragen om een inschrijving in het handelsregister en een attestatie van een bankrekening, of twee alternatieven accepteren, en de houder keurt het in één stap goed in plaats van twee keer te worden bevraagd.
Wat gebeurt er als de houder niet alles heeft wat gevraagd is?
De verifier kan aanvaardbare terugvalopties benoemen, in volgorde van voorkeur, en de wallet gebruikt de beste die de houder daadwerkelijk kan bieden. Zo kan een verifier vragen om een exact registratienummer waar dat bestaat en genoegen nemen met de statutaire naam waar dat niet bestaat, zonder een tweede verzoek te sturen of de houder weg te sturen.
Is DCQL specifiek voor de EUDI Wallet?
Nee. DCQL maakt deel uit van OpenID4VP en elke implementatie van dat protocol kan het gebruiken. Het EUDI Wallet-ecosysteem is een prominente gebruiker: het Architecture and Reference Framework noemt OpenID4VP met DCQL als de manier waarop credentials worden gepresenteerd, en daarom telt het voor iedereen die bouwt voor de Europese markt.
Helpt dit bij dataminimalisatie onder de GDPR?
Het maakt het minimum expliciet. Het verzoek benoemt welke gegevens nodig zijn, de houder ziet die lijst voordat hij goedkeurt, en de wallet geeft niets daarbuiten vrij. Daarmee wordt dataminimalisatie geen belofte in beleid maar een grens die de uitwisseling zelf afdwingt, en dat is veel eenvoudiger aan te tonen.
Bronnen
Deze pagina is informatief en vormt geen juridisch advies. Raadpleeg voor gezaghebbende informatie rechtstreeks de OpenID Foundation en de Europese Commissie.