Skip to main content

DCQL: Claim Sets (Selective Disclosure)

DCQL claim_sets allow a verifier to request preferred claims with fallback alternatives, enabling selective disclosure where only the minimum necessary data is shared.

Scenario: A service for people aged 16 and over verifies the age from the EU age verification attestation (doctype eu.europa.ec.av.1, see Age Verification). The verifier prefers the age_over_16 claim and falls back to the mandatory age_over_18 claim when the attestation does not carry age_over_16. A Person Identification Data (PID) credential carries no age claims (PID Rulebook v1.7), so an age check against a PID uses its birthdate.

For the underlying DCQL query, diagram and example, see the “Claim set for age verification (selective disclosure)” use case in our DCQL concepts article.

Fig 02: Verify age with minimal disclosure (Mandatory), for example by sharing an age-over-18 claim instead of a full date of birth.

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.

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.

Note: This presentation definition uses the redirect_uri client ID scheme with the direct_post response mode. As the request is not signed, the body has no signing key, and the server rejects cryptographicKeyFormat and cryptographicKeyIdentifier for such a request.

Once a presentation definition has been 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.

Request

Response

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.