Verify a credential

Create a presentation request, display it to a user, and receive verified identity attributes from their EUDI Wallet. This guide covers the minimal steps to complete a verification flow.

Before you begin

Access to a Truvity EUDIW Connector instance. The connector is not publicly available—contact Truvity at hello@truvity.com to get access.

A running connector instance with its public base URL configured and a callback URL pointing to your backend endpoint (for example, http://localhost:3000/callback). See connector architecture for the deployment model and how callbacks are delivered.
An X.509 access certificate configured in the connector. See Manage certificates to generate test certificates or import production ones.
A callback endpoint reachable from the connector over internal networking. The connector delivers verification results to this endpoint.
Access to the internal management API on port 8081.

The connector implements OID4VP under the High Assurance Interoperability Profile (HAIP). You don't need to configure protocol options—the connector applies HAIP-compliant settings by default.

Create a presentation request

Call POST /oidc4vp on the management API with a DCQL query. This example requests a PID credential with basic identity attributes.

note

The VCT values, requested claims, and credential values in this guide are examples. In production, request the attributes required by your use case and available in the target attestation scheme. Available attributes vary by issuer and member state.

cURL

curl -X POST http://connector:8081/oidc4vp \
  -H "Content-Type: application/json" \
  -d '{
    "dcql_query": {
      "credentials": [
        {
          "id": "pid",
          "format": "dc+sd-jwt",
          "meta": {
            "vct_values": ["urn:eudi:pid:1"]
          },
          "claims": [
            { "path": ["given_name"] },
            { "path": ["family_name"] },
            { "path": ["birthdate"] }
          ]
        }
      ]
    }
  }'

Example response:

{
  "state": "abc123",
  "same_device_request_uri": "openid4vp://?client_id=...&request_uri=https%3A%2F%2Fconnector.example.com%2Foidc4vp%2Fabc123%2Frequest%3Fflow_type%3Dsame-device",
  "cross_device_request_uri": "openid4vp://?client_id=...&request_uri=https%3A%2F%2Fconnector.example.com%2Foidc4vp%2Fabc123%2Frequest%3Fflow_type%3Dcross-device"
}

Store the state value to correlate with the callback later. Render cross_device_request_uri as a QR code or redirect the user to same_device_request_uri for same-device flows.

The response contains:

state—a correlation token to match the callback with this request.
same_device_request_uri—an openid4vp:// URI for same-device flows. Pass the full URI to the wallet as a deep link.
cross_device_request_uri—an openid4vp:// URI to render as a QR code for cross-device flows.

The request also supports optional parameters: expires_in (session TTL in seconds, defaults to ten minutes), transaction_data (contextual data bound to the request—see Use transactional data), and redirect_uri (enables same-device redirect behavior).

Handle the callback

Implement a callback endpoint that receives the PresentedCredentialsEvent from the connector. The event's status field indicates the verification outcome.

cURL

# Simulate a FULFILLED callback for testing
curl -X POST https://example.com:3000/callback \
  -H "Content-Type: application/json" \
  -d '{
    "status": "FULFILLED",
    "state": "abc123",
    "responseCode": "8k5CwzAseoGVK_bHQQJWMw",
    "credentials": {
      "pid": [
        {
          "issuer": "https://issuer.example.com",
          "claims": {
            "given_name": "Erika",
            "family_name": "Mustermann",
            "birthdate": "1964-08-12"
          },
          "signatureIsValid": true,
          "supportRevocation": false,
          "supportTrustAnchor": true,
          "isTrusted": false,
          "kbKeyId": "KrXxHnYsf-Inp0hW1M6r...",
          "kbSignatureIsValid": true
        }
      ]
    },
    "credentialsRaw": {
      "pid": [
        {
          "claims": "eyJiaXJ0aGRhdGUiOiIx...",
          "issuer": "https://issuer.example.com",
          "kbKeyId": "KrXxHnYsf-Inp0hW1M6r..."
        }
      ]
    }
  }'

For a FULFILLED status, the credentials map contains verified attributes keyed by the credential ID from your DCQL query. The credentialsRaw field contains the raw credential data without verification flags.

For the complete list of statuses and error codes, see the callback events reference.

Data handling responsibility

You are responsible for applying your own data retention and access control policies to credential data received through callbacks. The connector does not persist credential data after delivering the callback.

Next steps

Issue a credential—create a credential offer and deliver a signed credential to a wallet
KYC verification—verify customer identity using PID credentials
Passwordless authentication—replace passwords with key binding proof
Handle errors—handle non-success callback statuses

Create a presentation request​

Handle the callback​

Next steps​

Further reading​

Create a presentation request

Handle the callback

Next steps

Further reading