Verify credentials
Create an OID4VP verification session from a stored DCQL query, let a real wallet respond, and inspect the resulting session. The Admin Console is the operator path; the REST examples show the same configuration and protocol lifecycle for automation.
Audience: tenant admin or verifier integrator working in a tenant context.
Prerequisites: Onboard a tenant, configure a verifier and its public endpoint, and author or bind a DCQL query. Configure the applicable trust domains before relying on issuer or authority checks.
The examples below are sanitized verification captures. They document request shapes and response states, not a live customer deployment.
Configure the verifier and DCQL query
Use the verifier settings and DCQL binding screens to select the verifier, bind the query, and choose the trust-domain policy that applies to issuer validation.
- Admin Console
- REST API
Navigation: Protocols > Verifier > DCQL bindings and Settings
Deep link: #tenant={tenant}&surface=verifier&instance={instance}&area=dcql-bindings
Author the query and bind it to the verifier through the DCQL and verifier admin APIs. Keep the query id stable when a flow depends on it; versioned query changes remain addressable for in-flight sessions. See the DCQL REST API and verifier bindings.
Request a presentation
The verification request references the stored query. The response contains a wallet-facing request_uri and a backend status_uri:
- Admin Console
- REST API
Open the verifier's Test area, choose the bound query, and start a presentation request. The console can display the request URI for a wallet or QR-code handoff.
- 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 object from request_uri. The capture shows response_mode: direct_post, the verifier response_uri, and the negotiated formats.
- Overview
- Request
- Response
01a Fetch signed verification request object
Endpoint: GET /oid4vp/acme/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.
DCQL for SD-JWT VC and ISO mdoc
One query may ask for more than one credential format. In the captured request:
format: "dc+sd-jwt"usesmeta.vct_valuesto match an SD-JWT VC type and claim paths such asfamily_nameandgiven_name.format: "mso_mdoc"usesmeta.doctype_value(the mdocdocType) and namespace-qualified paths such asorg.iso.18013.5.1/family_name. The namespace is part of the claim path; do not treat an mdoc claim name as a flat SD-JWT claim.
The mdoc format identifier mso_mdoc and its docType are not interchangeable with an SD-JWT VC vct. Match each credential using the binding appropriate to its wire format.
Trust, status, and completion
During verification, validate the credential signature and holder binding, the issuer or authority against the effective trust-domain policy, and any applicable status information. A successful protocol response does not by itself make an untrusted issuer acceptable. Status checking is also separate from the presentation-session lifecycle: a credential can be cryptographically valid but revoked, suspended, expired, or otherwise unacceptable under policy.
The session moves through protocol states such as authorization_request_retrieved and, after a valid wallet response, a completed verified state. Operators can inspect or cancel a session in the console. REST clients can poll status_uri by correlation id:
- Admin Console
- REST API
Use the verifier Test or Sessions area to refresh the session state, inspect verification results, and cancel an expired or abandoned request.
- 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.
Polling is the client-controlled fallback when no callback consumer is configured. If the tenant configures verifier webhooks, consume the completion or failure callback as the event signal and use the session/status API for reconciliation and authoritative details. Do not assume that creating a request means a wallet has responded.
- 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.
The verifier's trust policy is configured under Settings > Trust domains. That screen writes one trust attachment on (OID4VP_VERIFIER, <verifierId>, CREDENTIAL_ISSUER_TRUST). If it is empty, the decision falls through to the tenant attachment; if the tenant has none either, the presentation fails closed. See Trust domains for the full cascade.
Wallet and mdoc PKI boundary
A real wallet that supports the requested OID4VP formats is required for an end-to-end protocol proof. Static captures prove the API shapes and the signed request contents; they do not prove wallet interaction, device authentication, mdoc issuer authentication, trust evaluation, status retrieval, or callback delivery.
For ISO 18013-5 mdoc terminology, a DSC (Document Signer Certificate) is the end-entity certificate that signs the MSO. An IACA (Issuing Authority CA) anchors DSCs. A VICAL is a separate ISO 18013-5 Annex C binary CBOR/COSE_Sign1 trust artifact. It must not be conflated with ETSI TS 119 602 JSON/JAdES trust-list material.