Skip to main content

DCQL: Multiple Credential Instances

Setting the DCQL query's multiple field to true allows a verifier to request several instances of the same credential type in a single verification flow.

Scenario: A loan provider requests six recent BankStatement credentials as part of assessing a loan application.

For the underlying DCQL query, diagram and narrative, see the “Loan application with multiple recent bank statements” use case in our DCQL concepts article.

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

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.

Note: With cryptographicKeyFormat x509, the cryptographicKeyIdentifier must be a key of your organisation that has a certificate chain. The page fills in such a key after you set the API key. Use Select key on the request to choose another key, or see the key management guide.

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 each matching bank statement and one entry of its claimSets from the response.
  • Send Verification:
    • Use the presentationId, <id>, the credential IDs as credentialIds and the claimSets entry as claimIds with the API available here to send the credentials to the verifier. The query has multiple: true, so it takes credentialIds in place of credentialId, and it 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.