# 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](/products/affinidi-elements/vta/get-started.md), or come back to them when you need to know why something behaves the way it does.

| Concept | What it explains |
| [Security model](/products/affinidi-elements/vta/concepts/security-model.md) | How 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 model](/products/affinidi-elements/vta/concepts/request-model.md) | Why 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. |
| [Identity](/products/affinidi-elements/vta/concepts/identity.md) | Why 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 contexts](/products/affinidi-elements/vta/concepts/keys-and-contexts.md) | How a VTA derives every key from one master seed, isolates applications into contexts, and which algorithms it uses for signing and key agreement. |
| [Secrets vault](/products/affinidi-elements/vta/concepts/vault.md) | What 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 access](/products/affinidi-elements/vta/concepts/roles-and-access.md) | Why 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 transfer](/products/affinidi-elements/vta/concepts/sealed-transfer.md) | How 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 cases](/products/affinidi-elements/vta/concepts/use-cases.md) | Concrete scenarios a VTA solves: remote signing, centralised secrets, AI agent memory, and driving a VTA directly from a Model Context Protocol (MCP) host. |

## Pages in this section
- [Security model](/products/affinidi-elements/vta/concepts/security-model.md): How 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 model](/products/affinidi-elements/vta/concepts/request-model.md): Why 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.
- [Identity](/products/affinidi-elements/vta/concepts/identity.md): Why 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 contexts](/products/affinidi-elements/vta/concepts/keys-and-contexts.md): How a VTA derives every key from one master seed, isolates applications into contexts, and which algorithms it uses for signing and key agreement.
- [Secrets vault](/products/affinidi-elements/vta/concepts/vault.md): What the VTA vault stores, 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 access](/products/affinidi-elements/vta/concepts/roles-and-access.md): Why 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 transfer](/products/affinidi-elements/vta/concepts/sealed-transfer.md): How 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 cases](/products/affinidi-elements/vta/concepts/use-cases.md): Concrete scenarios a VTA solves: remote signing, centralised secrets, AI agent memory, and driving a VTA directly from an MCP host.