DCQL explained: how a verifier asks a wallet for exactly what it needs
DCQL, the Digital Credentials Query Language, is the agreed way for an organisation to tell a wallet which credentials it needs and which details inside them. It is what turns a request such as "prove your company is registered in the Netherlands" into something every compliant wallet understands, without a separate integration per wallet.
The problem DCQL solves
A business wallet holds credentials of many kinds, issued by different bodies in different countries and stored in different technical formats. An organisation that only needs to confirm a registration number and a legal name has no portable way to ask for exactly that. It ends up either taking the whole credential, with everything else in it, or building a separate integration for each wallet it meets.
DCQL fixes the asking side. One standard request names the credentials wanted and the specific details wanted from each. The wallet checks it against what the holder actually has, shows the holder what is being asked for, and releases only that. The verifier gets a predictable answer no matter which wallet the holder uses.
1. Verifier
Asks for exactly the credentials and details it needs
2. Wallet
Works out which of the stored credentials fit the request
3. Holder
Sees what is being asked and approves releasing only that
4. Verifier
Receives the approved details, and nothing more
What a verifier can ask for
A request is a short list of what is needed. It can name one credential or several, and for each one it can name the specific details wanted rather than the whole thing. Three options on top of that cover almost every real case: fallbacks, combinations and a limit on which issuers are acceptable.
- Which credentials are needed, and which details inside each one.
- Acceptable fallbacks, in order of preference, for holders who do not have everything.
- Combinations, so a request can require one credential and either of two others.
- A restriction to issuers on an official trusted list, so credentials from anyone else are never offered.
Asking for a fallback
Not every holder carries the same credential. A verifier can name what it would prefer and what it would still accept, in order, and the wallet uses the best option the holder can actually satisfy. That avoids a second round trip and avoids turning away a customer who is only missing the nicest-to-have detail.
1. Preferred
Used when the credential carries both
2. Fallback
Used only when the first option cannot be met
Here the verifier would prefer a registration number together with the legal name, but will accept the legal name on its own when the holder’s credential does not carry a registration number.
Combining credentials in one request
Onboarding checks rarely rest on a single document. A verifier can require one credential and accept either of two others alongside it, all in one request, so the holder approves once and the verifier gets a complete answer in a single step.
Required
Company registration
One of
VAT registration
One of
Bank account attestation
A company registration is required. On top of that, either a VAT registration or a bank account attestation will do, and the holder only has to have one of them.
Accepting only trusted issuers
A verifier can narrow a request to credentials whose issuer appears on an official trusted list. Credentials from anyone else are never even offered to the holder, so a self-issued lookalike cannot reach the check in the first place.
The verifier says: only from issuers on an official EU trusted list
Registration credential from a listed issuer
The issuer appears on the trusted list
✓ Offered to the holder
Registration credential from an unlisted issuer
The issuer does not appear on the trusted list
✗ Not offered to the holder
This is a filter in the wallet, not a guarantee on its own. The verifier still checks the issuer against the trusted list when it validates what it received.
Where DCQL stands today
- DCQL is part of the OpenID4VP specification itself rather than a separate document, and it replaced an earlier dependency on DIF Presentation Exchange.
- The EUDI Wallet Architecture and Reference Framework names OpenID4VP as the presentation protocol and DCQL with it, so wallets and verifiers in the ecosystem are expected to support it.
- The reference wallets and verifiers in the EUDI Wallet programme have converged on DCQL, so a business wallet integration started today should assume it rather than the older alternative.
What this means for you
Verifier
One request format covers every wallet, and you only receive the details you asked for, which is less data to store, secure and justify.
Holder
You see exactly what is being asked before approving, and nothing beyond that leaves your wallet.
Issuer
Credentials you issue stay useful for partial checks, so one credential can serve many different purposes.
Technical deep dive
This page explains what the technology does and who it affects. Our developer documentation covers the implementation itself: the messages, the fields and the worked examples an integration team needs.
Read the technical documentationRelated terms
Frequently asked questions
How is DCQL different from DIF Presentation Exchange?
Both are ways for a verifier to describe what it wants from a wallet. Presentation Exchange is the older and broader of the two, designed to work across several protocols. DCQL is deliberately smaller and is defined inside OpenID4VP itself. The EUDI Wallet ecosystem has standardised on DCQL, so that is the one to plan around for the European market.
Can one request ask for more than one credential?
Yes, and that is one of the reasons it exists. A verifier can ask for a company registration and a bank account attestation in a single request, or accept either of two alternatives, and the holder approves it all in one step instead of being asked twice.
What happens if the holder does not have everything that was asked for?
The verifier can name acceptable fallbacks, in order of preference, and the wallet uses the best one the holder can actually satisfy. So a verifier can ask for a precise registration number where it exists and settle for the legal name where it does not, without sending a second request or turning the holder away.
Is DCQL specific to the EUDI Wallet?
No. DCQL is part of OpenID4VP and any implementation of that protocol can use it. The EUDI Wallet ecosystem is a prominent adopter: the Architecture and Reference Framework names OpenID4VP with DCQL as the way credentials are presented, which is why it matters for anyone building for the European market.
Does this help with data minimisation under the GDPR?
It makes the minimum explicit. The request states which details are needed, the holder sees that list before approving, and the wallet releases nothing beyond it. That turns data minimisation from a policy you promise into a limit the exchange itself enforces, which is a much easier thing to demonstrate.
Sources
This page is informational and does not constitute legal advice. For authoritative guidance consult the OpenID Foundation and the European Commission directly.