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