# Wallet Server

The Wallet Server is a server‑side implementation of a DID wallet. It is designed for:

* Running automated tests and integration pipelines without a mobile wallet
* Powering AI agents that need to perform wallet actions programmatically
* Simulating realistic wallet interactions with issuers and verifiers

It exposes a HTTP API over the Empeiria Wallet Core so you can:

* Manage DIDs (generate/import, list, resolve by method, serve did:web)
* Store and retrieve Verifiable Credentials (VCs)
* Run claim and presentation flows from QR content
* Operate in a multi‑tenant way scoped by the user’s JWT `sub`

Swagger UI is available at `/api-docs` and a raw OpenAPI JSON at `/swagger.json`.

## What It’s For

Mobile wallets are great for human‑in‑the‑loop flows. For automated testing or autonomous agents, you often need a non‑interactive, scriptable wallet that behaves like a real one. Wallet Server fills that gap by implementing the same claim/presentation flows you’d use with a mobile wallet, but as an HTTP API that can be driven by scripts, CI, or AI agent frameworks.

## Key Highlights

* DID methods: `did:empe` (mainnet), `did:empe:testnet` (testnet), and `did:web`
* End‑to‑end flows: claim (issuer QR) and presentation (verifier QR)
* VC management: import, list (with filters), fetch, delete
* Per‑request tenant scoping via JWT `sub` → isolates data by user
* did:web support with configurable host/path
* Health endpoints for ops (`/health/liveness`, `/health/readiness`)

## Architecture Overview

* Wallet Core: persistence abstractions and DID/VC operations
* Modules:
  * DID Management: generate/import/list/resolve DID docs, did:web endpoint
  * Credential Management: import, list/filter, get, delete
  * Flow Orchestration: initialize and confirm claim/presentation from QR
  * Core Module: request‑scoped user context, repositories, DI tokens
  * Auth Guard: `Authorization: Bearer <JWT>` validation (RS256/ES256)
  * Health: readiness/liveness checks

## Multi‑Tenancy

All storage operations are scoped to the authenticated user via a request‑scoped provider that reads `sub` from the validated JWT. This means a single Wallet Server can safely host many logical wallets.