Setup

We will setup a Verifier service inside of a tenant. If you don't have a tenant yet, you can learn how to create one here.

CURL

Endpoint: /v1/{target}/resource-api/services/create | API Reference

Example Request

curl -X 'POST' \
  'https://{orgID}.enterprise-sandbox.waltid.dev/v1/{target}/resource-api/services/create' \
  -H 'accept: */*' \
  -H 'Authorization: Bearer {yourToken}' \
  -H 'Content-Type: application/json' \
  -d '{
  "type": "verifier2",
  "baseUrl": "http://org.enterprise.localhost:3000",
  "clientId": "did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5Iiwia2lkIjoiU05JZ1ItTHZzSEUtNkhUUGxYYUpQVDVubHRZMFpqZlA0VkpTWEwzQ2ZkMCIsIngiOiJIVWM1ZHY1eFREV3VMVmZQcFdvVXBWTjZ1QTNJNzBsVzVnNEhoMG5VaDQ0In0",
  "clientMetadata": {
    "client_name": "walt.id Enterprise Verifier",
    "logo_uri": "https://cdn.walt.id/verifier/logo.png"
  }
}'

Body

{
  "type": "verifier2",
  "baseUrl": "http://org.enterprise.localhost:3000",
  "clientId": "did:jwk:eyJrdHkiOiJPS1AiLCJjcnYiOiJFZDI1NTE5Iiwia2lkIjoiU05JZ1ItTHZzSEUtNkhUUGxYYUpQVDVubHRZMFpqZlA0VkpTWEwzQ2ZkMCIsIngiOiJIVWM1ZHY1eFREV3VMVmZQcFdvVXBWTjZ1QTNJNzBsVzVnNEhoMG5VaDQ0In0",
  "clientMetadata": {
    "client_name": "walt.id Enterprise Verifier",
    "logo_uri": "https://cdn.walt.id/verifier/logo.png"
  }
}

Further metadata configuration options can be found in the official specification here

Path Parameters

  • orgID: - When performing operations within an organization, it is essential to use the organization's Base URL or another valid host alias. For example, if your organization is named test, your default Base URL will be test.enterprise-sandbox.walt.dev when using the sandbox environment.
  • target: resourceIdentifier - The target indicates the organization + tenant in which to create the new Verifier service and the service's ID ({organizationID}.{tenantID}.[NewVerifierServiceID]), e.g. waltid.tenant1.verifier1

Body Parameters

  • type: serviceType - Specifies the type of service to create. In our case verifier2
  • baseUrl: String - This URL will be included in the generated OIDC4VC offer, allowing the wallet to know how to reach the verifier. It should reflect your organization's base URL. The general format for this URL is https://{orgID}.yourEnterpriseStackUrl.com. For example, if your organization is named myorg and the Enterprise Stack is hosted at the domain enterprise-stack.com, your base URL would be: https://myorg.enterprise-stack.com.
  • clientId: String (optional) - The identifier the verifier presents to wallets during credential exchange. Supports multiple formats (defined in OID4VP 1.0, §5.9.3):
    • Omitted — unsigned sessions emit redirect_uri:<response_uri>. Prefer this for unsigned OID4VP; Wallet2 does not need a pre-registered allow-list.
    • Plain string (e.g. "verifier2") — Treated as OpenID4VP pre-registered. Wallet2 rejects it unless that exact id is in configuration.preRegisteredClients and the session destination is in that entry's redirect_uris. Registration plus in-band client_metadata is invalid_client.
    • DID (e.g. "decentralized_identifier:did:jwk:...") — A decentralized identifier that the wallet can resolve to verify the verifier's identity. Signed-only.
    • x509_san_dns:<hostname> (e.g. "x509_san_dns:verifier.example.com") — Client identity bound to the DNS name in the certificate's Subject Alternative Name extension. Wallets verify the signed request against the SAN in the provided certificate. Use together with key and x5c or x5cReferences. Signed-only.
    • x509_hash:<base64url-sha256-hash> — Client identity bound to the SHA-256 hash of the DER-encoded leaf certificate. Wallets verify the signed request and check that the certificate matches the hash. Use together with key and x5c or x5cReferences. Required by the HAIP profile. Signed-only.
  • clientMetadata (optional): Object - Verifier metadata config. Can be used to edit e.g. externally exposed human-readable verifier name and logo. Defaults to {"client_name": "Verifier"}. Learn more in general here or expand below to see object property options.

    Expand to learn more about metadata config object properties

    Metadata Config Object

     "metadataConfig": {
       "client_name": "walt.id Enterprise Verifier",
       "logo_uri": "https://cdn.walt.id/verifier/logo.png"
     }
    
    • client_name (optional) String: Human-readable string name of the verifier.
    • logo_uri (optional) String: URL string that references a logo for the verifier.

    Further metadata configuration options can be found in the official specification here

    Configuration Tip: The key, x5c, x5cReferences, and urlHost parameters set service-wide defaults that apply to all verification sessions. These can be overridden per-session during verification session creation if needed. To use x5cReferences, attach an X.509 Store as a dependency of the verifier.

  • urlHost (optional): String - Service-wide default base URL used to construct the QR code link or deep link for cross-device flows. Applied to all verification sessions unless overridden per-session. Defaults to "openid4vp://authorize" for standard OID4VP flows. For conformance testing with a browser-based authorization endpoint, use a full HTTPS URL. Not applicable for DC API flows (derived from request body instead).
  • key (optional): Object - Service-wide default signing key for authorization request JWTs. Applied to all verification sessions unless overridden per-session. Must be a serialized key in the format {"type":"jwk","jwk":{...}}. When signed_request: true or encrypted_response: true is set during verification session creation, a signing key is required — either configured here as a default or included in the verification session setup body.
  • x5c (optional): Array of Strings - Service-wide default X.509 certificate chain for the verifier's signing key. Applied to all verification sessions unless overridden per-session. Must be an ordered chain in PEM or DER-encoded, Base64-encoded format where the first certificate corresponds to the key. Required when using x509_san_dns: or x509_hash: as the clientId format, as wallets will use the certificate chain to verify the verifier's identity. Also explicitly required for signed Annex C (ISO 18013-7) requests. The leaf must chain to the wallet's configured trust anchors. If KeyUsage is present it must include digitalSignature; if absent, RFC 5280 treats the key as unrestricted. If ExtendedKeyUsage is present it must include TLS clientAuth (1.3.6.1.5.5.7.3.2) or mdoc reader authentication (1.0.18013.5.1.6); if absent, EKU is unrestricted. Include both extensions when issuing verifier Request Object leaves.
  • x5cReferences (optional): Array of Strings - Service-wide default X.509 Store certificate targets, e.g. waltid.tenant1.x509-store.cert1. Applied to all verification sessions unless overridden by session x5cReferences or session core.x5c. The store must be attached as a dependency.

Response Codes

  • 201 - Service created successfully.

Next Steps

  • Verify credentials — create your first verification session.
  • Default Requests — stop repeating the same verification session body. Save your usual verification query and settings once, then create sessions with just {}.
Last updated on September 29, 2026