Originally published together with European Wallet Consortium (EWC) partners and is available as pdf here.

Understanding Digital Credential Query Language (DCQL) in the EUDI Wallet Ecosystem - Unlocking secure and seamless digital identity transactions with DCQL in the EUDI Wallet ecosystem

Abstract: The European Digital Identity (EUDI) Wallet ecosystem is transforming how identities and credentials are managed and verified across Europe. Central to this transformation is the Digital Credential Query Language (DCQL), a JSON-based language designed to standardise and streamline the querying of verifiable credentials. This article explores the role of DCQL in enhancing interoperability, privacy, and security within the EUDI Wallet framework. The admin of a Relying Party (RP) can construct queries based on one or more query objects, offering rich control over how credentials are selected and combined during a presentation request. By enabling verifiers to specify precise requirements for credential attributes, DCQL ensures that users share only the data they need to, thereby preserving privacy while facilitating efficient and secure transactions. Through real-world use cases, such as those from the Bank of Transilvania and Fast Ferries, the article demonstrates how DCQL simplifies the credential verification process, improving user experience and operational efficiency. As a key component of the EUDI Wallet ecosystem, DCQL is poised to become a critical enabler of cross-border, secure, and privacy-respecting digital identity management in Europe.

Target Audience: Professionals and stakeholders in the world of verifiable credentials and EUDI Wallets who are keen to develop and use solutions based on DCQL, with real-world examples from payments

Editors: George Padayatti (iGrant.io, Sweden), Lal Chandran (iGrant.io, Sweden), Nikolaos Triantafyllou (University of Aegean, Greece)

1.0 Introduction

Digital Credential Query Language (DCQL, pronounced “dak-l”) is a core capability of the OpenID4VP (Verifiable Presentations) 1.0 specification. It provides a standardised, flexible, and privacy-preserving way to request verifiable credentials in digital identity systems. In the EUDI Wallet ecosystem, DCQL enables verifiers, such as businesses, government agencies, and service providers, to request only the precise information they need. This minimises data disclosure, improves security, and creates a consistent user experience across different use cases.

A key advantage is that the administrator of a Relying Party (RP) can build complex queries using one or more query objects, controlling how credentials are selected, combined, and presented. This is particularly valuable in regulated sectors like finance, healthcare, and transport, where proof of specific attributes must be provided without revealing unnecessary personal data.

This paper introduces DCQL, explains its key features, provides example scenarios, and demonstrates its application in real-world pilots such as payments and transport. It also highlights how DCQL benefits both individual and business wallet holders, ensuring interoperability and compliance across Europe.

1.1 Overview of Digital Credential Query Language (DCQL)

DCQL is a JSON-based query language used to specify the requirements for digital credentials that a verifier seeks from a wallet holder. A verifier (e.g., a service provider, government entity, or business) can send a DCQL query to the wallet holder to request specific claims or attributes within a credential, without requiring the wallet holder to share unnecessary data.

Unlike previous methods for presenting credentials (such as Presentation Exchange) [2], DCQL simplifies the query process, providing a standardised way to request and retrieve the exact data needed from a user’s digital wallet. It empowers the verifier to articulate the requirements of a given transaction clearly, and for the wallet to automatically present only the relevant information.

Key features of DCQL include:

• Simplified querying power: Instead of using complex filters or custom queries, DCQL enables the verifier to define the credential attributes needed clearly.
• Privacy preserving: Only the required data is shared, respecting the wallet holder’s privacy preferences.
• Interoperability: DCQL ensures that different wallets and service providers can interact with each other, as it is a standards-based solution within the OpenID4VP framework.

1.2 Business value and context

As the EUDI Wallet ecosystem expands across Europe, businesses will need to securely interact with digital credentials issued by governments, organisations, and other trusted parties. DCQL plays a critical role in this ecosystem by enabling businesses and service providers to efficiently query and verify credentials in a way that is both secure and privacy-respecting.

The business value of DCQL can be seen in several areas:

• Seamless user experience: DCQL streamlines the user experience by automating and standardising credential verification requests, reducing friction for both individuals and businesses.
• Privacy control and data minimisation: It enables individuals to share only the data required by a verifier, which is crucial for maintaining user trust and complying with privacy regulations such as the GDPR. From the Relying Party's perspective, this provides a tool for data minimisation, giving them the option to request only the data that is required.
• Operational efficiency: DCQL allows businesses to automate credential validation processes, saving time and resources by eliminating manual verification steps.
• Cross-Border interoperability: As part of the broader EUDI Wallet initiative, DCQL ensures that verifiers across different EU countries can request and accept credentials with confidence, enabling the smooth operation of cross-border services.

1.3 Glossary

To ensure clarity and understanding, here are some key terms used in this article:

• DCQL (Digital Credential Query Language): A JSON-based language used for querying and retrieving verifiable credentials in the EUDI Wallet ecosystem.
• OpenID4VP (Verifiable Presentations): A protocol that enables the sharing of verifiable credentials in a secure, privacy-preserving way.
• Verifiable Credential: A digital statement made by an issuer (e.g., a government or bank) that is cryptographically verifiable, such as an ID, diploma, or proof of payment.
• Claim: A statement made about an individual or entity, such as "age > 18" or "member of X organisation."
• Credential Set: A logical grouping of credential combinations (AND/OR), allowing the verifier to define acceptable combinations of credentials.
• Claim Set: A grouping of specific claims from within credentials, allowing a verifier to define combinations of claims for the credentials that are requested. It enables selective disclosure by defining which claims, and in what combinations, the verifier prefers.
• Verifier: The party requesting or validating the credentials, such as a bank, employer, or service provider.
• Wallet Holder: The individual or entity who owns and controls a digital wallet containing verifiable credentials.
• WU (Wallet Unit): means a unique configuration of a wallet solution that includes wallet instances, wallet secure cryptographic applications and wallet secure cryptographic devices provided by a wallet provider to an individual wallet user;

2.0 Features of DCQL

The Digital Credentials Query Language (DCQL) is a JSON-encoded query language that enables a Verifier to request Verifiable Presentations from a Holder's Wallet (Wallet Unit). It allows the Verifier to specify detailed requirements for the credentials it needs, including constraints on how different credentials and their constituent claims can be combined. The Wallet evaluates the DCQL query against the credentials it manages and returns only the presentations that match the request.

A valid DCQL query is a JSON object with two primary top-level properties: credentials, which is a required array of individual credential requests, and credential_sets. This optional array defines logical groupings and requirements across the requested credentials. This structure provides a robust framework for moving beyond simple credential requests to expressing complex, real-world data requirements in a standardised, machine-readable format.

2.1 The Credential Query

The fundamental building block of DCQL is the Credential Query object. Each object in the top-level credentials array represents a Credential Query, which is a request for the presentation of one or more credentials that match the specified criteria. It contains all the necessary parameters to describe the desired credential, including its format, issuer, and specific claims.

Field Name	Requirement	Description
id	REQUIRED	A unique string identifier for the query. This ID is used to reference the credential in the response and credential_sets definitions.
format	REQUIRED	A string specifying the required format of the credential (e.g., mso_mdoc, dc+sd-jwt). Valid identifiers are defined in the specification's appendix.
multiple	OPTIONAL	A boolean indicating if multiple credentials can be returned for this single query. Defaults to false.
meta	REQUIRED	An object for defining format-specific constraints on the credential's metadata and validity data. An empty object means no specific constraints are applied.
trusted_authorities	OPTIONAL	An array of objects specifying trusted issuers or trust frameworks. This helps the Wallet filter credentials from accepted authorities, enhancing privacy by preventing the disclosure of credentials that would likely be rejected.
require_cryptographic_holder_binding	OPTIONAL	A boolean indicating if the Verifier requires proof of cryptographic holder binding. Defaults to true.
claims	OPTIONAL	An array of Claim Query objects that specify the individual data claims requested from within the credential.
claim_sets	OPTIONAL	An array that specifies acceptable combinations of the claims defined in the claims array, allowing for alternatives.

Table 1: Credential Query Object Fields

The trusted_authorities field provides a crucial mechanism for Verifiers to signal trust requirements upfront. Rather than receiving a credential and then checking its issuer against a trust list, the Verifier can guide the Wallet to select only those credentials certified by a recognised authority. This is achieved by specifying a type and a set of values for that type.

Type Identifier	Description
aki	Matches the Authority Key Identifier from an X.509 certificate in the credential's trust chain.
etsi_tl	Matches an ETSI Trusted List that the credential's issuer is a member of.
openid_federation	Matches the Entity Identifier of a trust anchor in an OpenID Federation that the issuer is part of.

*Table 2: trusted_authorities Query Types*

2.2 Credential Set

While the credentials array defines the universe of credentials the Verifier is interested in, the optional top-level credential_sets array allows the Verifier to express logical rules about how those credentials should be combined to satisfy a use case.¹ This moves DCQL from a simple "shopping list" to a language capable of expressing complex business logic, such as "provide proof of identity AND (a utility bill OR a bank statement)."

A Credential Set Query is an object within the credential_sets array that defines one such logical requirement.

Field Name	Requirement	Description
options	REQUIRED	A non-empty array where each element is a list of Credential Query IDs. Each list represents one valid combination of credentials that satisfies the set's requirement.
required	OPTIONAL	A boolean indicating if this credential set is mandatory. Defaults to true.

*Table 3: Credential Set Query Object Fields*

The selection logic is straightforward but powerful. To fulfil the overall request, the Wallet MUST satisfy every Credential Set Query where required is true (or omitted). To satisfy a single Credential Set Query, the Wallet must be able to provide a set of credentials that matches at least one of the combinations listed in the options array. This enables Verifiers to define both mandatory requirements and acceptable alternatives in a single, structured query.

2.3 Claims Query

A "Claims Query" in DCQL refers to the specific data points, or claims, that a Verifier requests from within a particular credential. This is defined within a Credential Query object using the optional claims and claim sets properties. This mechanism is the engine of selective disclosure, allowing a Verifier to ask for just the information it needs, rather than the entire credential.

The claims property is an array of Claim Query objects, each pointing to a specific piece of data.

Field Name	Requirement	Description
id	REQUIRED (if claim_sets is used)	A unique string identifier for the claim, used for referencing it in the claim_sets array.
path	REQUIRED	A non-empty array representing a path to the claim within the credential's data structure.
values	OPTIONAL	An array of acceptable values for the claim. If present, the Wallet should only return the claim if its value is an exact match for one of the listed values.

*Table 4: Claim Query Object Fields*

In addition to the claims query, the verifier can also specify claim_sets property which enables the Verifier to express preferences and alternatives for the requested claims. It contains an array of arrays, where each inner array is a list of IDs from the claims array.

The logic for selecting claims is as follows:

• If claims are absent, the Verifier is not requesting any selectively disclosable claims.
• If claims are present but claim_sets is absent, the Verifier is requesting all claims listed in the claims array.
• If both claims and claim_sets are present, the Verifier is requesting one combination of claims from the claim_sets array. The order of the combinations expresses the Verifier's preference, from most preferred (first) to least preferred (last). The Wallet SHOULD return the first option it can satisfy.

This layered approach is fundamental to privacy preservation. A Verifier can ask for proof of age by creating a claim_sets array that prioritises a simple age_over_21 boolean claim over the more sensitive birth_date claim. The Wallet, following this preference, will provide the minimum information necessary to satisfy the request, empowering users and minimising data exposure.

2.4 Example scenarios

The following example scenarios demonstrate how DCQL is used to construct queries for different real-world scenarios.

2.4.1 Use case: Basic Credential Query with trusted authority

This query requests a single credential, a University Degree. It specifies that its issuer must be part of a known trusted authority, such as the EU Trust List, European Blockchain Service Infrastructure (EBSI), the OpenID Federation instance or similar, ensuring its authenticity.

Figure 01: Require a University Degree credential, only if issued by an authority listed in the EU Trust List or an OpenID Federation or a ledger (Mandatory) etc.

The query contains a single Credential Query object. The trusted_authorities field is used to filter for credentials issued by an entity within the specified federation.

{
  "credentials": [
    {
      "id": "university_degree_credential",
      "format": "dc+sd-jwt",
      "multiple": false,
      "meta": {
        "vct_values": [
          "https://credentials.example.com/identity_credential"
        ]
      },
      "trusted_authorities": [
        {
          "type": "etsi_tl",
          "values": [
            "https://raw.githubusercontent.com/EWC-consortium/ewc-trust-list/refs/heads/main/EWC-TL.xml"
          ]
        }
      ]
    }
  ]
}

2.4.2 Use case: Claim Set for age verification (Selective Disclosure)

This query asks for proof of age from a single credential, expressing a preference for a simple boolean claim over a full birthdate.

Figure 02: Verify age with minimal disclosure (Mandatory), for example by sharing an “Over 21” boolean or the full birthdate

Annotation: The claims array defines two possible claims: over_21 and birthdate. The claim_sets array lists ["over_21"] as the first, most-preferred option, and ["birthdate"] as the second, less-preferred alternative. This guides the wallet to disclose the least amount of information possible.

{
  "credentials": [
    {
      "id": "pid",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [
          "eu.europa.ec.eudi:pid.1"
        ]
      },
      "claims": [
        {
          "id": "over_21",
          "path": [
            "is_over_21"
          ]
        },
        {
          "id": "birthdate",
          "path": [
            "birth_date"
          ]
        }
      ],
      "claim_sets": [
        [
          "over_21"
        ],
        [
          "birthdate"
        ]
      ]
    }
  ]
}

2.4.3 Use case: Credential Set for proof of identity (Alternatives)

This query asks the user to provide one form of identification, accepting a PID, a Photo ID, or a Driver's License.

Figure 03: Accept any one identity document (Mandatory), Passport, Driving Licence or PID to confirm identity

Annotation: Three distinct Credential Query objects are defined. The top-level credential_sets object contains a single requirement with three options. Each option is a list containing a single credential id. This tells the wallet that providing any one of these three credentials will satisfy the request.

{
  "credentials": [
    {
      "id": "pid",
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "urn:eu.europa.ec.eudi:pid:1"
      }
    },
    {
      "id": "photo_id",
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "eu.europa.ec.eudi.photoid.1"
      }
    },
    {
      "id": "driving_license",
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "org.iso.18013.5.1.mDL"
      }
    }
  ],
  "credential_sets": [
    {
      "options": [
        [
          "pid"
        ],
        [
          "photo_id"
        ],
        [
          "driving_license"
        ]
      ],
      "required": true
    }
  ]
}

2.4.4 Use case: KYC request with Photo ID and address proof

This query illustrates a comprehensive Know Your Customer (KYC) verification process, which requires a photo ID for name verification and a separate proof of address. For this, either a utility bill or a bank statement is acceptable.

Figure 04: Require a Photo ID (Mandatory) plus proof of address via Utility Bill or Bank Statement (Mandatory)

Annotation: This query combines multiple concepts. It defines three credentials. The credential_sets array has two required sets. The first set has one option: ["photo_id"], making it mandatory. The second set has two options: ["utility_bill"] or ["bank_statement"], allowing the user to provide either one to prove their address. \

{
  "credentials": [
    {
      "id": "photo_id",
      "format": "mso_mdoc",
      "claims": [
        {
          "path": [
            "family_name"
          ]
        }
      ]
    },
    {
      "id": "utility_bill",
      "format": "dc+sd-jwt",
      "claims": [
        {
          "path": [
            "address"
          ]
        }
      ]
    },
    {
      "id": "bank_statement",
      "format": "dc+sd-jwt",
      "claims": [
        {
          "path": [
            "address"
          ]
        }
      ]
    }
  ],
  "credential_sets": [
    {
      "options": [
        "photo_id"
      ],
      "required": true
    },
    {
      "options": [
        [
          "utility_bill"
        ],
        [
          "bank_statement"
        ]
      ],
      "required": true
    }
  ]
}

2.4.5 Use case: Student transport pass with mandatory and optional credentials

This example demonstrates the full expressive power of DCQL by combining mandatory and optional credential sets with selective claim disclosure in a single, cohesive query.

Scenario: A city's public transport authority offers a discounted travel pass to students. To apply, a student must:

1. Prove their identity: This is a mandatory requirement. The authority needs their full name and date of birth.
2. Prove their student status: This is also mandatory. The authority will accept either a digital Student ID Card or an official Enrolment Letter. From this credential, they need to verify the university's name and confirm the student's enrolment status is "active".
3. Prove local residency (optional): Students who are also local residents may be eligible for an additional discount. This is an optional requirement. The authority will accept either a Utility Bill or a Rental Agreement as proof of address.

Figure 05: Require a PID and a proof of being a student via Student ID or Enrolment Letter (Mandatory). Also, proof of local address via Utility Bill or Bank Statement for additional discount (Optional)

DCQL Implementation: This scenario is translated into a DCQL query that defines five potential credentials and three credential sets to enforce the business logic.

• Credential Queries: Five Credential Query objects are defined in the credentials array: one for a national ID, one for a student ID, one for an enrolment letter, one for a utility bill, and one for a rental agreement.
• Claim Sets: Within each credential query, claims and claim_sets are used to specify exactly which data points are needed, such as full_name and date_of_birth from the national ID, or address from the proof of residency documents. This ensures minimal data disclosure.
• Credential Sets: Three Credential Set Query objects are defined in the credential_sets array:
  1. A mandatory set requiring the pid.
  2. A mandatory set requiring either the student ID card or the enrolment letter.
  3. An optional (required: false) set allowing the user to provide either a utility_bill_doc OR a rental_agreement_doc.

This structure provides an explicit, machine-readable request that gives the user flexibility while ensuring the transport authority receives all necessary information in a privacy-preserving manner.

{
  "credentials": [
    {
      "id": "pid",
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "urn:eu.europa.ec.eudi:pid:1"
      },
      "claims": [
        {
          "id": "full_name",
          "path": [
            "full_name"
          ]
        },
        {
          "id": "dob",
          "path": [
            "date_of_birth"
          ]
        }
      ],
      "claim_sets": [
        [
          "full_name"
        ],
        [
          "dob"
        ]
      ]
    },
    {
      "id": "student_id_card",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [
          "student_id"
        ]
      },
      "claims": [
        {
          "id": "student_id",
          "path": [
            "student_id"
          ]
        },
        {
          "id": "university_name",
          "path": [
            "university_name"
          ]
        }
      ],
      "claim_sets": [
        [
          "university_name",
          "student_id"
        ]
      ]
    },
    {
      "id": "enrolment_letter",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [
          "employment_letter"
        ]
      },
      "claims": [
        {
          "id": "status",
          "path": [
            "status"
          ]
        },
        {
          "id": "university_name",
          "path": [
            "university_name"
          ]
        }
      ],
      "claim_sets": [
        [
          "university_name",
          "status"
        ]
      ]
    },
    {
      "id": "utility_bill_doc",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [
          "utility_bill_doc"
        ]
      },
      "claims": [
        {
          "id": "address",
          "path": [
            "address"
          ]
        }
      ]
    },
    {
      "id": "rental_agreement_doc",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [
          "rental_agreement_doc"
        ]
      },
      "claims": [
        {
          "id": "address",
          "path": [
            "address"
          ]
        }
      ]
    }
  ],
  "credential_sets": [
    {
      "options": [
        "pid"
      ],
      "required": true
    },
    {
      "options": [
        [
          "student_id_card"
        ],
        [
          "enrolment_letter"
        ]
      ],
      "required": true
    },
    {
      "options": [
        [
          "utility_bill_doc"
        ],
        [
          "rental_agreement_doc"
        ]
      ],
      "required": false
    }
  ]
}

2.4.6 Use case: Loan application with multiple recent bank statements

This example demonstrates how a loan provider (Relying Party/ Verifier) can request multiple instances of a single credential type.

Scenario: The Loan provider is assessing a loan application. As part of affordability and risk checks, the applicant must share the last 6 months of bank statements.

Figure 06: Require six recent Bank Statements (Mandatory) to assess affordability as part of a loan application

The request allows multiple credentials of the same type (bank_statement) to be returned in a single query. This is achieved by setting "multiple": true. The format is dc+sd-jwt, and the meta.vct_values filter ensures only credentials explicitly identified as bank_statement are considered.

The multiple field enables the Wallet to provide more than one matching credential in response to a single credential query. This is particularly useful in scenarios like this, where each month’s statement is a separate credential issued by the same authority. The Verifier receives all 6 statements in one presentation, maintaining both efficiency and the structured verification flow.

{
  "credentials": [
    {
      "id": "bank_statement",
      "format": "dc+sd-jwt",
      "multiple": true,
      "meta": {
        "vct_values": [
          "https://credentials.bank.com/bank_statement"
        ]
      },
      "claims": [
        {
          "id": "statement_period",
          "path": [
            "period"
          ]
        },
        {
          "id": "account_number",
          "path": [
            "account_number"
          ]
        },
        {
          "id": "account_holder_name",
          "path": [
            "account_holder_name"
          ]
        }
      ],
      "claim_sets": [
        [
          "statement_period",
          "account_number",
          "account_holder_name"
        ]
      ]
    }
  ]
}

2.4.7 Use case: Delivery service restricted to specific postal codes

This example demonstrates how a delivery service (Relying Party / Verifier) can request an address credential but only accept it if the postal code matches one of a predefined list of allowed areas.

Scenario: A grocery delivery company offers same-day delivery only to customers in certain postal code areas. When a customer signs up, the company must verify their address and confirm the postal code is in the allowed list before activating their account.

Figure 07: Require a PID and an address credential with a postal code matching 43242 or 43243 for same-day delivery eligibility (Mandatory)

The request targets an address credential (dc+sd-jwt format) and uses the values field to explicitly state the acceptable postal codes. This field contains an array of possible claim values, and the wallet must only return credentials where the claim’s value exactly matches one of the listed entries. This makes the eligibility check straightforward and ensures the verifier only receives relevant credentials.

{
  "credentials": [
    {
      "id": "residential_address",
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [
          "https://credentials.gov.example/address_credential"
        ]
      },
      "claims": [
        {
          "id": "full_address",
          "path": ["street_address"]
        },
        {
          "id": "postal_code",
          "path": ["postal_code"],
          "values": ["43242", "234234"]
        },
        {
          "id": "city",
          "path": ["locality"]
        },
        {
          "id": "country",
          "path": ["country"]
        }
      ],
      "claim_sets": [
        [
          "full_address",
          "postal_code",
          "city",
          "country"
        ]
      ]
    }
  ]
}

3.0 EUDI Wallet - A unified experience for individuals and businesses

One of the primary objectives of the EUDI Wallet ecosystem is to provide a seamless and user-friendly experience for both natural persons (individuals) and businesses. For individuals, this means greater control and privacy when sharing only the necessary information. For businesses, it ensures streamlined verification workflows that are standards-based and interoperable. DCQL plays a central role in enabling this unified experience by providing a common, structured way for businesses to request and verify credentials consistently across a wide range of use cases, and for individuals to present credentials securely while preserving privacy.

3.1 Business Wallets - Powering flexible business requirements

Using DCQL, Business Wallet administrators can define precise and privacy-preserving credential requests by using one or more query objects. Although the specification only allows a flat list of query objects, this structure is highly versatile. It enables both OR and AND conditions through thoughtful configuration.

By including multiple query objects in a single request, a Business Wallet can offer alternative ways for the holder to fulfil the requirement. This effectively creates a logical OR. For example, it may accept any one of several valid credentials, such as different forms of address proof or registration documents.

To express a logical AND, where multiple credentials are required together, the administrator can include all necessary credential definitions within a single query object, grouped under the same credential_sets. This instructs the Wallet to present all listed credentials at once, simulating an AND condition.

Business scenario	Credential combination example
Accepting any one of several recognised identities	The administrator can configure the request to accept any one of: PID, passport, driver's licence, or student ID. This provides flexibility for the holder to choose from several forms of recognised identity documents.
Offering a choice of single credentials or a group of proofs	The administrator can configure the query to accept any one of four individual credentials, or a combined proof of, for example, a VAT certificate and tax compliance document, enabling flexible options for the holder.
Mixing single credentials and grouped combinations	The administrator can set the configuration to accept one of the first two credentials (e.g., passport or driver's licence) or a combined set of three credentials from another category (e.g., proof of address + tax compliance + bank statement).
Multiple instances of the same credential	The administrator can allow the holder to choose one or more available instances of the same credential. For example, the holder can present multiple receipts for refunds from the employer, providing flexibility in proof of purchase or transaction.
Request more data to provide additional services	Administrators can configure optional data requests for additional services. For example, suppose the relying party offers extra services (e.g., discounts or loyalty benefits). In that case, they can request additional data from the holder, such as membership status or service preferences, allowing for more tailored user interactions.

3.2 Natural Person Wallets - Enhancing user experience and control

For individuals, DCQL ensures that they share only the relevant credentials required for a specific interaction. Whether it’s verifying identity, age, membership, or other attributes, DCQL queries allow for clear and concise requests, enabling a smooth flow of information.

One of the key advantages of DCQL is the flexibility it offers. Users can choose which credential(s) they wish to share, based on what is requested. For example, a service may request a Passport or a PhotoID as a form of identity verification, and the individual can choose which credential they are more comfortable sharing, as long as the requested attribute (e.g., identity, age) is included in both. This flexibility not only simplifies the process of data-sharing but also allows users to select the most appropriate credential to meet the requested requirements, enhancing both privacy and user autonomy.

Example use case scenarios for individuals are as follows:

Scenario	Credential(s) presented
Age verification for online purchases	The user may share proof of age, without disclosing full birthdate or other personal details.
Flexible identity verification	The user can select a passport, photo ID, or driver's licence, depending on preference and availability.
Accessing membership or discounts	The user may share their membership validity or student status without revealing any other personal information.
Decide to share optional data	The user may share additional data for certain benefits with a clear lawful basis for use.

4.0 Case study from EWC LSP merchant-led payments

In this section, we examine how DCQL is utilised in real-world, merchant-led payment systems to enhance the customer experience while ensuring compliance with privacy and regulatory standards.

4.1 Bank of Transilvania: Integrating EUDI Wallets with DCQL

The Bank of Transilvania, one of Romania’s leading banks, has integrated iGrant.io Business Wallet (Organisation Wallet Suite) and demonstrated its integration in production, linking a user's bank account with their EUDI Wallet. This was the first live demonstration of payments in production with EUDI Wallets as part of the Payments Task Force efforts within the EU Digital Identity Wallet Consortium (EWC), in collaboration with UAegean, VISA, Worldline, Fast Ferries, BPC, and iGrant.io.

During the EWC pilots, the DIF Presentation Exchange [2] was used to facilitate credential exchanges, where the bank would request specific credentials, such as proof of identity through a passport, PID, PhotoID, or Driver's License, before linking the bank account. While this approach worked, there is room for improvement by shifting to DCQL, which enhances both user experience, privacy and efficiency in the verification and linking process.

Use of DCQL enables the Bank of Transilvania to provide alternative requests. For example, a Passport or Photo ID is used to verify the individual's identity before issuing the Payment Authenticator. The bank’s Business Wallet sends a DCQL query specifying that it requires proof of identity and income with specific attributes (e.g., personal number). The user’s EUDI Wallet presents only the personal number from among the available credentials. This is similar to the case example in Chapter 2.4.3 Use case: Credential Set for proof of identity (Alternatives).

4.2 Fast Ferries: Integrating EUDI Wallets with DCQL

Cyclades Fast Ferries, a dynamic Greek passenger ferry operator, integrated the EUDI Wallet into its online checkout to enable identity‑validated, card-based payments and student discounts. This cross-border, merchant-led pilot was carried out within the EU Digital Identity Wallet Consortium (EWC) together with UAegean, Banca Transilvania (BTRL), Visa, Worldline, BPC and iGrant.io, and marked one of the first live demonstrations of using the EUDI Wallet in a real e-commerce flow.

Earlier EWC payment pilots relied on the DIF Presentation Exchange [2] to handle credential requests. In that setup, the merchant (and PSP) typically asks the user to present whole documents, e.g., a Passport/PID for identity, a student card for the discount, plus a loyalty credential. Although this worked, moving to DCQL streamlines the flow: verifiers can declare exactly which attributes they need, express alternatives, and thereby deliver a smoother experience with stronger privacy and greater operational efficiency.

With DCQL, Fast Ferries crafted minimal, choice-aware queries. To grant a student discount, it can accept either a Student ID or a European Student Card; it can optionally request a Loyalty Card credential; and combine these with the requirement for a payment authenticator, patterns that align with Chapters 2.4.3 (Alternatives) and 2.4.4 (Complex sets). The query can also mandate cryptographic holder binding and restrict issuers via trusted_authorities, ensuring only trusted sources qualify. The result is that the user’s EUDI Wallet shares only the necessary claims (e.g., status = "active", university name, loyalty card number, payment token reference) instead of the entire credentials, achieving the same business goals with tighter privacy controls and a faster checkout.

4.3 Benefits of DCQL in merchant-led payment scenarios

4.3.1 Benefits for the end-user

The transition to DCQL provides the end-user with several advantages, improving their overall experience and privacy during the account linking process:

Clearer Transparent Communication: With DCQL queries, users understand exactly what data is being requested, providing clarity and transparency throughout the process and leading to a more positive user experience.

Faster Verification: By using DCQL, only the relevant claims are requested, speeding up the verification process and reducing unnecessary steps. This leads to a quicker and smoother user experience, making it easier to onboard and link accounts quickly.

Greater Control for Users: DCQL queries enable users to share specific claims selectively. For example, a bank may request proof of age, and the user can easily approve just that claim, without exposing any unnecessary information from the entire document.

Enhanced Privacy: With DCQL, users only share the necessary data, such as proof of age or nationality, rather than submitting entire documents like passports or driver’s licenses. This ensures that the user's sensitive information is protected, maintaining privacy. There is also an opportunity to learn more about the usage purpose, etc., as per the GDPR and ISO 27560 by taking this approach.

4.3.2 Benefits for the bank

For the Bank of Transilvania, adopting DCQL results in significant operational and compliance benefits:

Increased Efficiency: DCQL enables the bank to request only the necessary claims, such as age or nationality, rather than processing full documents. This reduces the complexity of verifying identities and streamlines the entire account linking process, enhancing operational efficiency.

Simplified data regulatory compliance: By using DCQL, the bank ensures that only the required data is shared with it, making it easier to comply with GDPR and other privacy regulations. With this privacy-first approach, the bank minimises the exposure of sensitive data and reduces the risk of privacy breaches.

Cost efficiency: By querying specific claims instead of handling full credentials, the bank can reduce costs related to data storage, processing, and security. This approach leads to cost savings and reduces the administrative burden associated with handling large sets of sensitive data.

Building user trust: By requesting only the essential claims from the user, the bank demonstrates transparency and a commitment to user privacy, fostering trust with customers. This can lead to increased adoption rates and a positive brand reputation.

4.3.3 Benefits for the merchant

For Cyclades Fast Ferries (and, more broadly, any merchant integrating the EUDI Wallet), adopting DCQL yields concrete UX, compliance, and cost advantages:

Faster checkout, higher conversion: By expressing exactly which attributes are needed (e.g., status = "active" for a student discount) and supporting alternatives (Student ID or enrolment letter), DCQL minimises friction and abandonment at payment time.

Privacy-by-design: Selective disclosure means the merchant never sees (or stores) full documents when they’re not needed. A smaller PII footprint directly reduces GDPR exposure, breach impact, and the burden of data governance (retention, access control, deletion workflows).

Flexible business logic: Through credential_sets and claim_sets, the merchant can model rich eligibility rules (mandatory vs. optional credentials, acceptable alternatives, preferred claim combinations) as data, not bespoke code. This shortens change cycles (e.g., adding another accepted student credential) and simplifies A/B testing of business rules.

Trust signalling and automated filtering: Using trusted_authorities, the merchant can pre-filter acceptable issuers and schemes, reducing manual review and fraud risk while keeping the user journey smooth (the wallet hides ineligible credentials before the user even tries). Additionally, this can enable the merchants to enforce specific policy rules (e.g. student discounts only to Greek university students)

Better auditability & policy alignment: Each DCQL query is a machine-readable, auditable artefact that can be mapped to the merchant’s privacy notices, purpose limitation statements, and discount policies—simplifying audits and demonstrating accountability (e.g., GDPR, ISO 27560).

Lower integration and maintenance costs: Encoding verification logic declaratively in DCQL reduces custom integration code for the merchant. Over time, this lowers maintenance costs and accelerates the rollout of new credential-based products (e.g., age-gated services, special citizen categories discounts, etc).

In essence, DCQL lets merchants like Fast Ferries prove eligibility, apply discounts, and complete payments with minimal data, improving conversion and trust while shrinking compliance and operational burdens.

7.0 Conclusions

The introduction of Digital Credential Query Language (DCQL) represents a significant advancement in establishing a secure, user-friendly, and interoperable digital identity ecosystem. By enabling businesses and organisations to request only the necessary data from digital wallets, DCQL provides a unified querying approach across various industries, enabling seamless integration with merchant systems. By adopting DCQL, banks, merchants and service providers can leverage the power of query languages for credential requests, reduce friction in user interactions, and ensure compliance with privacy regulations. DCQL also ensures that privacy is preserved, while also facilitating the seamless exchange of credentials across borders and industries.

As the EUDI Wallet ecosystem grows, the role of DCQL will become even more critical in harmonising user experiences and simplifying credential verification. By adopting DCQL, businesses can streamline processes, enhance user experiences, and ensure compliance with EU regulations. As this language becomes the standard for querying credentials, the opportunities for innovation within the digital identity landscape will expand, driving a more interoperable, secure, and privacy-conscious future for all EU citizens and businesses.

References

[1] OpenID Foundation (2025) OpenID for Verifiable Presentations 1.0, Available at: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html (Accessed: 22-July-2024)

[2] Decentralised Identity Foundation (DIF) (2025) Presentation Exchange 2.0, Available at: https://identity.foundation/presentation-exchange/ (Accessed: 22-July-2024)

[3] iGrant.io (2025) Business Wallets – Enabling Trust and Scale in the European Digital Identity (EUDI) Wallet Ecosystem. [Online], Available at: https://www.igrant.io/articles/business-wallets-enabling-trust-and-scale-in-the-european-digital-identity-eudi-wallet-ecosystem.html (Accessed: 8 August 2025).