Concepts

Concept pages covering the VTA’s security model, identity, key derivation, and access control.

The mental model behind a VTA: how it protects keys, how identity works, how keys are derived and isolated, and who can do what. Read these alongside the Quickstart, or come back to them when you need to know why something behaves the way it does.

ConceptWhat it explains
Security modelHow an Affinidi-hosted VTA protects keys with a Trusted Execution Environment, what PCR0 pinning verifies, and what the fail-closed and anti-rollback guarantees cover.
Request modelWhy every VTA operation is defined once and reachable identically over REST, DIDComm, or the CLI, and how DID-based challenge-response authentication replaces a shared API key.
IdentityWhy every actor in a VTA has its own verifiable identity, which DID method each one uses and why, and how the Administrator DID and VTA URL fit around it.
Keys and contextsHow a VTA derives every key from one master seed, isolates applications into contexts, and which algorithms it uses for signing and key agreement.
Secrets vaultWhat the vault stores and why a given secret cannot simply be derived, how entries are scoped to a context, which roles can read or write them, and how it differs from the VTA’s other stores.
Roles and accessWhy a VTA has five distinct roles instead of one shared credential, what each one can and cannot do, and how role and context together bound what a DID can reach.
Sealed transferHow a VTA delivers a private key or secret to a caller over the network without exposing it in transit, even to whoever relays the message.
Use casesConcrete scenarios a VTA solves: remote signing, centralised secrets, AI agent memory, and driving a VTA directly from a Model Context Protocol (MCP) host.