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.