OpenVTC Wiki

4 min read

Verifiable Trust Agent (VTA)

Part of github.com/OpenVTC/verifiable-trust-infrastructure

The Verifiable Trust Agent is the central service of the Verifiable Trust Infrastructure. It’s an always-on key management and signing service that handles the hardest part of decentralized identity: keeping cryptographic keys secure while making them usable.

What It Does

The VTA is a signing oracle — applications send it data to sign, and it returns signatures. The private keys never leave the VTA’s security boundary. This means applications that need to issue credentials, update DIDs, or send authenticated DIDComm messages don’t need to manage keys themselves.

Key capabilities:

  • Key generation and derivation — all keys derive from a single BIP-39 seed via BIP-32, supporting Ed25519, X25519, and P-256
  • Signing oracle — sign payloads on behalf of applications without exposing keys
  • DID management — create and manage did:webvh and did:key identifiers
  • Session management — JWT-based authentication with DIDComm challenge-response
  • Access control — role-based ACL (Super Admin → Admin → Initiator → Application → Reader → Monitor)
  • Backup and restore — encrypted backups using Argon2id
  • Audit logging — every operation is logged for compliance

Architecture

The VTA is built with Axum (Rust async web framework) and exposes two parallel API paths:

  1. REST API — HTTP endpoints authenticated with EdDSA JWTs
  2. DIDComm API — encrypted DIDComm v2 messages via a mediator

Both paths converge on a shared operations layer. Storage uses fjall, an embedded LSM key-value store.

Application Contexts

A key architectural concept is Application Contexts — logical namespaces that group keys and DIDs. Each context (e.g., “vta”, “mediator”, “my-app”) gets its own BIP-32 derivation sub-tree, isolating keys between applications while deriving from the same master seed.

The VTA Seal

After initial bootstrap (via an interactive setup wizard), the VTA “seals” itself — offline CLI commands are disabled, and all management must go through authenticated REST or DIDComm APIs. This prevents unauthorized local access.

Deployment Models

Local Development

cargo run --package vta-service --features setup -- setup  # Interactive setup
cargo run --package vta-service                             # Start the server

Hardware Enclave (AWS Nitro)

The VTA can run inside an AWS Nitro Enclave — a hardware-isolated virtual machine where not even the host operating system can access the VTA’s memory. In this mode:

  • Keys are unsealed via AWS KMS, pinned to the enclave’s attestation (PCR0 + PCR8)
  • Communication happens over vsock (virtual socket) rather than network
  • An 8-layer defense-in-depth security model protects key material
  • An enclave proxy handles external routing

Seed Storage Backends

The master seed can be stored in:

  • OS keyring (default for development)
  • AWS Secrets Manager / GCP Secret Manager / Azure Key Vault
  • KMS (for enclave mode)
  • Config file (not recommended for production)

SDK Integration

Third-party services integrate with the VTA via the vta-sdk crate:

// Simplified integration pattern
use vta_sdk::integration;
 
let vta = integration::startup(&config).await?;
let signature = vta.sign(payload).await?;

The SDK handles authentication, token refresh, secret caching, and offline fallback. This is the recommended way for services in the ecosystem (like the affinidi-webvh-service) to interact with the VTA.

Recent Development

Per-release detail lives on the workspace entity — see Recent Development for the full activity log. VTA-relevant highlights, reverse chronological:

v0.6.0 (in flight) — runtime service management

  • Unified pnm services … CLI for enable / disable / list / rollback on a live VTA
  • Snapshot-store / fail-forward semantics
  • P0–P5 merged on main; P6 (e2e matrix) in PR

v0.5.0 — 2026-05-04 — sealed-bootstrap

  • Every secret-bearing transfer to/from the VTA moves as an HPKE-sealed bundle
  • Template-driven DID minting
  • DIDComm protocol surface can be enabled, disabled, or migrated on a running VTA without rebuilding it
  • Refresh tokens single-use (RFC 6749 §10.4)
  • verify_vta_authorization_credential returns a typestate
  • server_internal_super_admin replaced with a sealed InternalAuthority marker

v0.4.x — April 2026

  • Production-grade DIDComm service v0.2 (lifecycle management, message expiry, problem-report logging)
  • TEE deployment hardening
  • Client DID documents and capabilities discovery

v0.3.x — March/April 2026

  • SDK integration module
  • Imported secrets
  • Lightweight DIDComm auth
  • Reader role
  • Automatic token refresh

v0.2.0 — March 2026

  • TEE / Nitro Enclave support
  • Signing oracle
  • Backup / restore
  • P-256 keys
  • Prometheus metrics

The direction has decisively shifted from “make the VTA usable” to “make the VTA’s runtime surface mutable in production without downtime or rebuilds.”

See also: verifiable-trust-infrastructure, bip32-key-derivation, openvtc

Graph View

Backlinks