> 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/getting-started/tutorial/understanding-concepts.md).

# Understanding Key Concepts

Before we dive in, let's clarify a few core components of the Empeiria ecosystem:

* **Issuer**:\
  The Issuer is responsible for creating and issuing Verifiable Credentials. In this guide, the Issuer service is deployed for you via the One-Click Deployment portal. It stores credential schemas (which define the structure of credentials) and, upon request, creates credential offers that users can claim with their wallet.
* **Schema**:\
  A schema defines the fields and data types that a credential will include. By uploading a schema to the Issuer, you tell it the exact data structure of the credentials it will produce. For example, a "KYC Verifiable Credential" schema may include `age`, `first_name`, and `last_name`. Each schema is identified by a name and version, and combining it with a credential format produces a **credential configuration** (for example, `KYCCredential@1.0:sd-jwt`) that credential offers reference by id.
* **Verifier**:\
  The Verifier checks the authenticity and validity of credentials presented by a holder. It ensures that a credential was issued by a trusted Issuer and that it meets certain criteria—for example, that the user is over 18. The Verifier runs inside the same One-Click deployment as the Issuer; you register a verifier identity for it in the operator console. It creates authorization requests (presented to the user as a QR code or deep link) and tracks the outcome through a verification session.
* **Empe DID Wallet**:\
  A reference mobile wallet (available for iOS/Android) used to store and present credentials. The wallet holds its own decentralized identifier (such as a `did:key` or `did:web`). Users scan QR codes displayed by the Issuer or Verifier flows with this wallet. When issuing a credential, the user scans a code to add the credential to their wallet. When verifying, they scan a verification QR code to prove they hold a valid credential. Because credentials can be issued as SD-JWT, the wallet supports **selective disclosure**—the user can reveal only the specific claims a Verifier asks for, rather than the entire credential.

**Overall Flow:**

1. Create a One-Click deployment (it hosts both the Issuer and Verifier), then register a verifier identity in the console.
2. Upload a schema to the Issuer so it knows how to structure credentials.
3. Issue credentials by having the user submit their info, and display a QR code from the Issuer.
4. The user scans the issuance QR code with the wallet to claim the credential.
5. To verify, request a verification QR code from the Verifier and show it to the user.
6. The user scans the verification QR code with their wallet and presents the credential. When the check passes, the verification session moves to the `ResponseVerified` state. Your backend observes this by subscribing to the session's real-time event stream (`/verification-sessions/{sessionId}/events`) or by querying the session — and can then treat the user as verified.

In the following steps, we'll set everything up and run through these flows in detail.


---

# 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/getting-started/tutorial/understanding-concepts.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.