> 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/verifier/core-responsibilities.md).

# Core Responsibilities

The Verifier's responsibilities fall into five areas:

1. **Verification Request Management**:
   * Creates OpenID4VP authorization requests, choosing a response mode (`direct_post`, `direct_post.jwt`, `dc_api`, or `dc_api.jwt`; default `direct_post.jwt`) and an OpenID4VP draft version (`v1`, `v1.draft21`, or `v1.draft24`; default `v1`).
   * Specifies the required credentials and attributes through a configurable query language — either a **DCQL** query or a **DIF Presentation Exchange v2** definition. Exactly one of the two must be supplied per request.
   * Signs each authorization request with the verifier's DID, so wallets can authenticate the relying party before disclosing any data. The signing DID is taken from the `verifierId` when it is itself a DID, or from the optional `signingDid` field in the request body.
   * Returns an authorization-request URI (`openid4vp://...`) and a verification session id, and can render the same request as a scannable QR code.
2. **Credential Validation**:
   * Checks the cryptographic signatures of presented credentials, supporting **SD-JWT VC** and **JWT-VC** formats.
   * Resolves the issuer's DID document to confirm the signing key and the issuer's identity. Issuer DIDs are resolved over standard methods — `did:web` (served over an HTTPS origin) and `did:key` — rather than through any centralized registry.
   * Honors **SD-JWT selective disclosure**, so only the claims the holder chooses to reveal are processed.
   * Validation today rests on DID resolution and signature verification; revocation-status and domain-linkage checks are planned additions (see [Future Enhancements](/develop/verifier/future-enhancements.md)).
3. **Real-Time Communication and Feedback**:
   * Streams verification session updates over **Server-Sent Events (SSE)**, so your application learns about progress and the final outcome as it happens.
   * Emits a `session` event carrying the current session state immediately on subscribe and on each subsequent change, plus a `ping` keepalive every 15 seconds to hold the connection open.
4. **Session Management**:
   * Tracks each verification session through its lifecycle — `RequestCreated` → `RequestUriRetrieved` → `ResponseVerified`, or `Error` if the response fails validation. Sessions also carry an `expiresAt` timestamp after which the request is no longer accepted.
   * Exposes the session state (by polling `GET /verification-sessions/:sessionId` or by subscribing to its SSE stream) so your integration can trigger its own login or access-control logic once a session reaches `ResponseVerified`. The Verifier itself does not issue application tokens or sessions — your relying party decides what a successful verification grants.
5. **Integration Support**:
   * Provides a REST + SSE surface for the full presentation flow: create an authorization request (with optional QR-code rendering), then read or watch the resulting verification session.
   * Offers a standalone **`POST /credentials/verify`** endpoint for ad-hoc credential checks outside the presentation flow — useful when you already hold a compact SD-JWT or JWT-VC string and simply want to confirm its validity. The response reports `isValid`, the detected `format`, and the decoded `payload` (plus `prettyClaims` for SD-JWT), or an `error` message when the credential is invalid.

For example, a standalone credential check:

```json
// POST /credentials/verify
{
  "credential": "eyJhbGciOiJFZERTQSJ9.eyJ2Y3QiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLmNvbS92Y3QvZW1wbG95ZWUtYmFkZ2UiLCJlbXBsb3llZV9pZCI6IkUtMTAyNCJ9.signature~WyJzYWx0IiwiZnVsbF9uYW1lIiwiQWRhIExvdmVsYWNlIl0~WyJzYWx0IiwiZGVwYXJ0bWVudCIsIkVuZ2luZWVyaW5nIl0~"
}
```

A valid SD-JWT VC returns:

```json
{
  "isValid": true,
  "format": "dc+sd-jwt",
  "payload": { "vct": "https://issuer.example.com/vct/employee-badge", "iss": "did:web:issuer.example.com:...", "iat": 1718000000, "employee_id": "E-1024" },
  "prettyClaims": {
    "vct": "https://issuer.example.com/vct/employee-badge",
    "employee_id": "E-1024",
    "full_name": "Ada Lovelace",
    "department": "Engineering"
  }
}
```

The `format` field reports the detected credential format: `dc+sd-jwt` for a verified SD-JWT VC, and `jwt_vc` for a verified JWT-VC.

In every flow, the relying party stays in control of what a verified presentation unlocks.


---

# 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/verifier/core-responsibilities.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.