Skip to main content

DCQL: Values Constraint

The DCQL values constraint restricts accepted claim values to a predefined allowed list, enabling a verifier to enforce eligibility criteria directly in the query.

Scenario: A delivery service requests a PID credential (in dc+sd-jwt format) containing the holder's residential address, accepting only postal codes from an allowed list.

For the underlying DCQL query, diagram and example, see the “Delivery service restricted to specific postal codes” use case in our DCQL concepts article.

Fig 07: Require a PID and an address credential with a postal code matching 43242 or 43243 for eligibility.

Before you start: This example asks the holder wallet for credentials that it already holds. Issue them to your wallet first on Issue the Test Credentials:

Step 1: Get the API Key (Verifier Admin)​

To obtain your API key, sign in to the dashboard and go to Account > Developer APIs > Create API Key (see Get API Keys). Once you have your API key, enter it in the field below and click the Set API Key button to save it for future use.

Signing keys: The requests on this page that name a signing key sign with an x509 key of your organisation: a key with a certificate chain. After you set the API key, the page fills in such a key. To choose another key, click the key label next to a signing key field in a request, for example cryptographicKeyIdentifier. To create a key, attach a certificate or see your keys, follow the key management guide. To add your certificate to the NXD trust list, see trust list registration.

Step 2: Create Presentation Definition (Verifier Admin)​

To create a presentation definition for requesting proof, you can run the code block below using the Run button. Alternatively, you can manually copy the code block and use it in the body of the API request provided here.

In this use case, the verifier expresses a requirement for a residential address credential where the postal code is in an allowed list of delivery zones.

Request

Response

Once a presentation definition is created, the presentationDefinitionId is autofilled in Step 3 automatically (and updated whenever Step 2 is re-run). You can also reuse the same presentationDefinitionId to verify multiple credentials.

Step 3: Create Verification Request (Verifier/Relying Party)​

When you run Step 2 on this page, the presentationDefinitionId field below is autofilled automatically (and updated whenever Step 2 is re-run). If you are executing the APIs yourself, replace <presentationDefinitionId> with the ID obtained in Step 2. To create the verification request, execute the code block below using the Run button. Alternatively, you can manually copy the JSON and use it in the body of the API available here.

After receiving the response, toggle the button provided to dynamically generate a QR code. The EUDI Wallet/Holder can then accept the verification request using the Data Wallet (or any other EU Digital Identity Wallet) by either scanning the QR code or directly accessing the verification request on their mobile device, such as via a browser.

Request

Response

Users can copy the presentationExchangeId from the JSON response for use in Step 5 to read the verification.

Step 4: Send and Receive Verifiable Presentation (Holder)​

The holder wallet consents to send the requested credentials.

  • Receive Verification:
    • Use the requestUrl (step 3) with the API available here to receive the verification.
    • Copy the presentationId from the JSON response received from Receive Verification for the filter call.
  • Filter Verification:
    • Use that presentationId with the API available here to find matching credentials.
    • Save the <id> of the credential query, the <credentialId> of a matching credential and one entry of its claimSets from the response.
  • Send Verification:
    • Use the presentationId, <id>, <credentialId> and the claimSets entry as claimIds with the API available here to send the credentials to the verifier. The query has claim_sets, so claimIds is mandatory.

Step 5: Send and Receive Verifiable Presentation (Verifier/Relying Party)​

  • The verifier (relying party) receives the requested credentials. Read them with the Read Verification API. In the response, isVerified holds the result, presentation holds the disclosed claims of each credential, and presentationValidity holds the result of each check.
  • vpToken holds the raw tokens that the wallet sent. Decode an SD-JWT or a JWT token with the JWT Decoder.