Verify credentials
This guide covers DCQL configuration, OID4VP presentation requests, and verification results. Complete these linked prerequisites first:
- Platform foundations and authentication boundaries for the service client's token and the public/session token boundary.
- Tenant provisioning and confidential-client access for the tenant verifier.
- Credential designs and claims and Issuer configuration for the credential formats and claim paths the verifier will accept.
- Credential issuance if you need a credential to present during the test.
- Trust-domain creation and verifier binding for issuer anchors, admissions, eligibility, and the verifier attachment.
The order is: create the verifier and DCQL query, bind a query version, configure trust, then create the OID4VP request and verify the presentation.
Postman correlation: In the canonical EDK Enterprise collection, run 3. Tenant APIs > Verify credentials, with Trust domains when you need to check which issuers the verifier accepts. The query lane is 1. List verifiers, 2. Get the verifier client settings, 3. List DCQL queries, 4. Create a DCQL query, 5. List query bindings of the verifier, and 6. Bind the query to the verifier; the request lane is 7. List verification templates, 8. Create a request from a template or 9. Create a request for a query, 10. Fetch the signed request object, and 11. Get the verification status. The list requests store the response-derived verifier, query, and template ids that later requests need. Verification polling is deliberately separate from credential issuance and does not send an administration bearer token to public protocol endpoints.
Define the DCQL query
Each credential format has its own DCQL identifier and claim paths.
| Credential | DCQL format | Type match | Claim paths |
|---|---|---|---|
| SD-JWT VC | dc+sd-jwt | meta.vct_values | JSON claim names such as family_name |
| ISO mdoc | mso_mdoc | meta.doctype_value | Namespace and element pairs such as org.iso.18013.5.1/family_name |
| W3C VCDM 1.1 JWT | jwt_vc_json | VCDM 1.1 context and types | Paths below the VCDM 1.1 credential object |
| W3C VCDM 2.0 JWT | jwt_vc_json-ld | VCDM 2.0 context and types | Paths for the VCDM 2.0 credential |
Do not reuse an SD-JWT claim path for mdoc or a VCDM 1.1 query for a VCDM 2.0 credential.
- Admin Console
- REST
- Open Protocols > Verifier and select the verifier.
- Under DCQL bindings, select the query and version.
- Under Settings > Trust domains, choose the Trust mode (Verified only or, where offered, Trust all) and select the Allowed trust domains used for issuer validation.
- Save the verifier configuration.
Create or update the DCQL query, then bind a specific query version to the verifier. Keep a version available while any active session still refers to it.
See the DCQL API and verifier bindings.
Request a presentation
- Admin Console
- REST
- Open the verifier Test page.
- Select the bound query.
- Create a presentation request.
- Give the request URI or QR code to the wallet.
The create response contains a wallet-facing request_uri and a server-facing status_uri.
- Overview
- Request
- Response
Create verification request
Endpoint: POST /oid4vp/backend/auth/requests
Captured response: 201 Created
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Connect an environment to rewrite this call to real service bases and run it.
The wallet retrieves the signed authorization request from request_uri and sends its presentation to the advertised response_uri.
- Overview
- Request
- Response
Fetch signed verification request object
Endpoint: GET /oid4vp/cap0924b/oid4vp/request-uri/e2e-verify-001
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Connect an environment to rewrite this call to real service bases and run it.
Read the verification result
- Admin Console
- REST
Open the verifier Test or Sessions page. Refresh the session to inspect its state, the selected credentials, the returned claims, and each verification result. Cancel a request that is no longer needed.
Poll status_uri until the wallet responds or the session expires. If callbacks are configured, use the callback as a notification and read the session API for the full result.
- Overview
- Request
- Response
Poll verification status
Endpoint: GET /oid4vp/backend/auth/requests/e2e-verify-001
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Connect an environment to rewrite this call to real service bases and run it.
- Overview
- Request
- Response
Cancel verification session
Endpoint: DELETE /oid4vp/backend/auth/requests/e2e-verify-001
Captured response: 204 No Content
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Connect an environment to rewrite this call to real service bases and run it.
Creating a request does not mean that a presentation was accepted. A completed session must report success for every required check.
Review the checks
Read these results separately:
- The credential signature is valid for the issuer key or certificate.
- The holder or device binding required by the format is valid.
- The issuer is allowed by the selected trust domain.
- The credential is within its validity period.
- The referenced status list is valid and the indexed entry is acceptable.
- The returned credential and claims satisfy the DCQL query.
For mdoc, also verify the issuer-signed MSO, DSC certificate chain, device authentication when required, and the CWT status entry. The DSC must chain to an accepted IACA. See VICAL and CWT status for that configuration.