> 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.