> 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/understand/intro.md). # EVDI Architecture The **End-to-End Verifiable Data Infrastructure (EVDI)** provides a standards-based platform for managing decentralized digital identities and Verifiable Credentials (VCs). It is composed of multiple subsystems, each covering a distinct role in the Self-Sovereign Identity (SSI) lifecycle. Across the platform, identifiers are created and resolved by the service itself, credentials are signed off-chain, and holders decide exactly what to share. ## Core Components ### 1. One Click Deployment One Click Deployment streamlines the setup and configuration of **Issuer** and **Verifier** services. By automating the deployment process, it eliminates much of the manual complexity involved in standing up secure SSI environments. Users gain: * **Rapid Provisioning**: Instantly deploy Issuers and Verifiers, each registered against a service-created DID, with no manual key or DID-document handling. * **Centralized Management**: Easily access, monitor, and maintain deployed components through a unified dashboard. ### 2. Issuer Service The **Issuer Service** is responsible for creating and delivering Verifiable Credentials using the **OpenID4VCI** protocol over a standards-based HTTP API. Key features include: * **DID Management**: Creates and serves its own **`did:web`** documents over HTTPS and **`did:key`** identifiers, using Ed25519 keys. * **Schema Management**: Defines credential structure with JSON-Schema templates and supports versioning. A schema together with a format yields a **credential configuration id** of the form `Name@Version:format` (for example, `EmployeeBadge@1:sd-jwt`). * **Credential Issuance**: Issues credentials in **SD-JWT VC** (`vc+sd-jwt`) and **JWT-VC-JSON** (`jwt_vc_json`) formats, cryptographically signed with Ed25519 keys held in the service's internal key store. * **Credential Offers**: Creates `openid-credential-offer://` offers (optionally rendered as a QR code) that wallets claim through the OpenID4VCI **pre-authorized code flow**, with an optional PIN. * **Direct Signing**: Exposes a server-to-server endpoint that returns a signed credential without a wallet round-trip. ### 3. Verifier Service The **Verifier** requests and validates Verifiable Presentations from wallets and checks the credentials inside them, using the **OpenID4VP** protocol. Its responsibilities include: * **Credential Verification**: Validates cryptographic signatures against the issuer's published DID document and checks compliance with the requested claims — no central registry lookup is required. * **Flexible Queries**: Requests exactly the credentials and claims needed using either a **DCQL** query or a **DIF Presentation Exchange v2** definition. * **Real-Time Feedback**: Each request creates a **verification session** whose state can be polled or subscribed to over **Server-Sent Events (SSE)** for live updates as the wallet responds. * **Standalone Verification**: Beyond the full presentation flow, a direct endpoint verifies a single compact credential string (SD-JWT or JWT-VC) and returns its decoded claims. ### 4. Holder Wallets Holders store their DIDs and credentials and present them to verifiers. The platform supports two complementary holder options: * **Empe DID Wallet**: A reference mobile wallet application available for iOS and Android. It lets holders securely manage DIDs and credentials, receive Verifiable Credentials, and deliver signed presentations to verifiers. * **Cloud Wallet**: A server-side, multi-tenant holder built into the same backend. It speaks the same OpenID4VCI and OpenID4VP protocols a mobile wallet uses, so credential-offer and presentation-request URIs can be claimed and presented over plain HTTP — ideal for automated tests, CI pipelines, and agents acting as a holder programmatically. Both interact with Issuers and Verifiers through the same standards-based flows, so a credential issued to a mobile wallet and one claimed by the cloud wallet are verified identically. ## Identifiers and Trust DIDs and their documents are created and resolved by the service itself, with no on-chain registration step. The platform issues two methods: * **`did:web`** — the DID document is self-hosted by the service and served over HTTPS, resolvable at `/:uuid/did.json`. Resolving the DID simply means fetching that document. * **`did:key`** — a deterministic, self-describing identifier whose public key is encoded directly in the DID, so no hosting is required. A DID document lists the public keys and verification methods needed to validate the credentials and presentations associated with that identity. This makes trust **self-contained**: a verifier establishes authenticity by checking the issuer's signature against the public key published in its DID document — no central authority, ledger query, or registry lookup is involved. The EMPE DID method (`did:empe`) and EMPE blockchain exist in the wider Empeiria ecosystem to provide shared, tamper-evident trust infrastructure. Within this platform, however, issuance, holding, and verification are performed off-chain: DID documents and schemas are stored by the service, credentials live in the holder's wallet, and authenticity is established through cryptographic signatures and selective disclosure rather than by querying a ledger. ## Bringing It All Together **One Click Deployment** kickstarts your ecosystem by provisioning fully configured Issuer and Verifier services. The **Issuer Service** offers credentials to wallets over OpenID4VCI, and the **Verifier Service** requests and checks presentations over OpenID4VP. Both resolve DIDs directly — fetching `did:web` documents over HTTPS or decoding `did:key` identifiers — to verify signatures without central intermediaries. This architecture forms a complete SSI environment: 1. **Issuer** defines schemas, signs credentials, and offers them to wallets. 2. **Holder Wallets** (the Empe DID Wallet on mobile, or the server-side cloud wallet) let individuals and agents store and present their own credentials. 3. **Verifier** requests presentations and validates credentials against the claims you require, with live session feedback over SSE. With **selective disclosure** via SD-JWT, holders reveal only the specific claims a verifier needs while the issuer's signature over the whole credential still validates. All operator endpoints are protected by **OIDC JWT Bearer** authentication; the `admin` role is required only on the agent/DID and wallet-management routes. By adhering to W3C Verifiable Credentials and DID Core standards, and by building on OpenID4VCI and OpenID4VP, the EVDI ecosystem keeps your SSI solutions interoperable, future-proof, and user-centric. --- # 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/understand/intro.md?ask=&goal= ``` `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.