> For the complete documentation index, see [llms.txt](https://docs.empe.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.empe.io/develop/intro/verifier_data.md).

# Verifier Data Description

A **Verifier** requests and validates credential presentations. You create one in the operator console (see [Creating a Verifier](/develop/intro/create_verifier.md)); it is identified by a DID it uses to sign requests. This page describes the data that identifies a Verifier and how to reach its API.

A Verifier builds **OpenID4VP** authorization (presentation) requests — shared as a QR code or an authorization-request URI — tracks the resulting verification sessions, and validates presented **SD-JWT VC** and **JWT-VC-JSON** credentials, including selective disclosure.

***

## Identity

* **verifierId:** The Verifier's identifier, used in every authorization request. In the console it is the **DID** (`did:web:...` or `did:key:...`) you select when creating the Verifier, and that DID becomes the default key for signing the OpenID4VP authorization requests it sends to holders. Via the raw API the verifierId may instead be any identifier (the service generates one if you omit it); when it is not a DID, supply a `signingDid` in each authorization request so the Verifier has a key to sign with.
* **clientMetadata** *(optional)*: OpenID4VP client metadata attached to the Verifier.

## Where the Verifier API Lives

The Verifier API is served at your deployment's base URL (`fullHost`), with interactive docs at `/api-docs` (raw OpenAPI at `/api-docs-json`). In the current One-Click setup a single deployment hosts both the Issuer and Verifier APIs, so this is the same base URL as the Issuer's; in other setups the Verifier may run under its own host. Administrative calls use the same admin **Bearer token** as the rest of the deployment — see [Authenticating to Your Deployment](/develop/intro/authenticating-to-your-deployment.md).

***

## Cryptographic Identity

The Verifier has its own self-hosted **Decentralized Identifier (DID)** — a `did:web` or `did:key` using Ed25519 keys — which it uses to sign the OpenID4VP authorization requests it sends to holders. For a `did:web` Verifier, the corresponding DID document is served over HTTPS at `/:uuid/did.json` (also reachable at `/:uuid/.well-known/did.json`), so holders can resolve it and verify the request signature.

* **didDocument:** A JSON object describing the Verifier's DID. It includes:
  * **id:** The DID identifier (for example, `did:web:example-name.evdi.app:<uuid>`).
  * **@context:** The JSON-LD contexts for the document, including the DID v1 context and the Ed25519 2018 signature suite context.
  * **verificationMethod:** The Verifier's signing keys. Each entry uses an **Ed25519** key (`type: "Ed25519VerificationKey2018"`), with an **id**, a **controller** (the DID that controls the key), and a **publicKeyBase58** value (the Base58-encoded Ed25519 public key).

***

## Example

Creating a Verifier (`POST /agent/verifier`) returns its identifier:

```json
{
  "verifierId": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
}
```

For a `did:web` Verifier, the corresponding DID document is available at its hosted `did.json`:

```json
{
  "id": "did:web:example-name.evdi.app:646941a4-1d89-60e7-d66e-6afddccb7a68",
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2018/v1"
  ],
  "verificationMethod": [
    {
      "id": "did:web:example-name.evdi.app:646941a4-1d89-60e7-d66e-6afddccb7a68#key-1",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:web:example-name.evdi.app:646941a4-1d89-60e7-d66e-6afddccb7a68",
      "publicKeyBase58": "<base58-encoded-public-key>"
    }
  ],
  "authentication": [
    "did:web:example-name.evdi.app:646941a4-1d89-60e7-d66e-6afddccb7a68#key-1"
  ],
  "assertionMethod": [
    "did:web:example-name.evdi.app:646941a4-1d89-60e7-d66e-6afddccb7a68#key-1"
  ]
}
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.empe.io/develop/intro/verifier_data.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.