# Glossary

> Canonical terms used throughout the VTA documentation and the pnm CLI.

The Verifiable Trust Agent (VTA) holds signing keys and secrets centrally and provisions a verifiable DID for each registered application and AI agent. The Personal Network Manager (PNM) is the operator CLI (pnm) you use to manage a VTA remotely.

Clear, consistent terminology for the terms you see in pnm output and don’t recognise yet.

## Core concepts

| Term | Meaning |
| VTA | Verifiable Trust Agent: the appliance that holds keys and secrets and signs on your behalf. |
| PNM | Personal Network Manager: the pnm CLI, the standard client for operating a VTA. |
| Context | A named, isolated namespace within a VTA: its own derived keys and its own access control list. [Keys and contexts →](/products/affinidi-elements/vta/concepts/keys-and-contexts.md) |
| Master seed | The single BIP-39 seed every VTA key is derived from. Generation and recovery differ between self-hosted and Affinidi-hosted. [Keys and contexts →](/products/affinidi-elements/vta/concepts/keys-and-contexts.md#master-seed) |
| VTA slug | PNM’s short local name for one VTA, passed with --vta <vta-slug>. Defaults to the tail segment of the VTA DID. |

## Identity

| Term | Meaning |
| DID | Decentralised Identifier: a [W3C standard](https://www.w3.org/TR/did-core/) identifier that resolves to a document of its own keys and endpoints, no central registry required. A VTA mints one for itself and for every application or agent it registers. |
| VTA DID | The DID a VTA mints for itself at deployment: how PNM knows which VTA it’s talking to. [Identity →](/products/affinidi-elements/vta/concepts/identity.md) |
| Administrator DID | The did:key identity holding admin role at a VTA. Self-hosted: you generate it. Affinidi-hosted: minted for you at bootstrap. [Identity →](/products/affinidi-elements/vta/concepts/identity.md#administrator-did) |
| VTA URL | The VTA’s public REST endpoint. Resolved automatically for did:webvh; supplied explicitly for did:key. |
| did:webvh | A [DID method](https://identity.foundation/didwebvh/) that publishes its document at a web domain, with a signed, publicly resolvable change log. Always used for a hosted VTA’s own identity; the recommended choice for self-hosted too. |
| did:key | A [DID method](https://w3c-ccg.github.io/did-key-spec/) that encodes the public key directly into the identifier, so it resolves with no hosting or lookup. Used for the Administrator DID and for application and client credentials on any VTA. Not an option for a hosted VTA’s own identity, which is always did:webvh. |

## Messaging and transport

| Term | Meaning |
| DIDComm | [DIDComm Messaging v2.1](https://identity.foundation/didcomm-messaging/spec/v2.1/): an end-to-end-encrypted messaging protocol in which DIDs address each other directly, with no shared API key or network allowlist. One of the two transports a VTA serves, alongside REST. [Request model →](/products/affinidi-elements/vta/concepts/request-model.md) |
| Mediator | A relay service with a DID of its own, holding one message inbox per DID it serves. A VTA and its callers each connect to the same mediator, which routes messages between them by DID. It carries the traffic without being able to read it, since payloads are encrypted to the recipient. A mediator is a separate deployment from the VTA, either Affinidi-hosted or [self-hosted](/products/affinidi-elements/affinidi-messaging/didcomm-mediator.md). |
| setup_acl | The VTA setting that registers its own DID with the mediator’s access control list on connecting. Mediators running in ExplicitAllow mode drop messages for unregistered DIDs, so this is what stops replies going missing. |
| TSP | Trust Spanning Protocol: an experimental, opt-in transport on self-hosted VTAs, gated behind a build feature and off by default. DIDComm through a mediator is the default on every VTA. |

## Keys and cryptography

| Term | Meaning |
| Key ID | The identifier PNM prints for a key. For a derived key, it’s the same value as its Derivation Path, not a short opaque ID, and contains / characters, so percent-encode it before use in a URL. An internal (CSPRNG-generated) key has no derivation path and uses a caller-supplied Key ID instead. |
| Derivation Path | The BIP-32 path a key was derived at, such as m/26'/2'/2'/0'. |
| BIP-32 | A Bitcoin standard for deriving a whole tree of keys from one seed, so backing up the seed backs up every key. Every VTA key is a BIP-32 derivation. |
| BIP-39 | A Bitcoin standard for representing a seed as a mnemonic: ordinary words from a fixed 2048-word list, easier to write down than raw hex. A self-hosted VTA’s master seed is a 24-word BIP-39 mnemonic. |
| Ed25519 | A widely-used signature scheme (EdDSA over Curve25519), fast and hard to misuse. The signing algorithm every VTA key uses. |
| X25519 | The Diffie-Hellman key-agreement function on the same Curve25519 as Ed25519: two parties derive a shared secret without exposing a private key. VTA uses it for encryption (HPKE, sealed transfer); derived from a key’s Ed25519 private key. |

## Security and attestation

| Term | Meaning |
| TEE | Trusted Execution Environment: a hardware-isolated area of a processor, confidential and tamper-evident even from its own host OS. An [AWS Nitro Enclave](https://aws.amazon.com/ec2/nitro/nitro-enclaves/) is the kind an Affinidi-hosted VTA runs inside. [Security model →](/products/affinidi-elements/vta/concepts/security-model.md) |
| PCR | Platform Configuration Register: a boot-time hash of a piece of software or firmware, checked later against a known-good value. |
| PCR0 | The PCR measuring the enclave image itself: the exact software running inside it. The value you pin before trusting a hosted VTA. [PCR0 pinning →](/products/affinidi-elements/vta/concepts/security-model.md#pcr0-pinning) |
| PCR8 | The PCR measuring the signing certificate for the enclave image, alongside PCR0. |
| Pinning | Telling PNM the PCR0 value you expect before it connects, so it can refuse to proceed on a mismatch. |
| Trust On First Use (TOFU) | A model where a client records an identity at first contact and refuses any later change to it. PNM’s bootstrap is a hardened variant: the first connection is also checked against the PCR0 you pinned in advance, so an unexpected enclave is refused rather than recorded. |
| Fail-closed | Refusing an operation outright when a check cannot be satisfied, rather than continuing in a reduced mode. A PCR0 mismatch fails closed: the bootstrap stops instead of proceeding unverified. |
| Anti-rollback protection | A tamper-resistant counter blocking a restored older backup from rolling an enclave back to a compromised build. |

## Access control

| Term | Meaning |
| ACL | Access control list: the record of every DID a VTA knows, each with a role and, usually, a set of allowed contexts. |
| Role | One of five access levels an ACL entry can hold: Admin, Initiator, Application, Reader, or Monitor. [Roles and access →](/products/affinidi-elements/vta/concepts/roles-and-access.md) |
| Allowed contexts | The contexts an ACL entry can act in. Empty means unrestricted for Admin, restricted to nowhere for every other role. |

## Credential delivery and bootstrap

| Term | Meaning |
| HPKE | Hybrid Public Key Encryption ([RFC 9180](https://www.rfc-editor.org/rfc/rfc9180)): encrypts a message to a recipient’s public key, combining key agreement (X25519 here) with fast symmetric encryption. |
| Sealed transfer | The HPKE-based mechanism a VTA uses to deliver a private key or secret to a recipient over the network without exposing it in transit. [Sealed transfer →](/products/affinidi-elements/vta/concepts/sealed-transfer.md) |
| Bundle | The ASCII-armored, HPKE-sealed package a sealed-transfer exchange produces, such as the output of pnm bootstrap request. |
| Digest | A SHA-256 hash of a bundle’s contents, communicated out-of-band and checked with --expect-digest so a substituted bundle is detected. |
| pnm bootstrap connect | The one command that bootstraps PNM against an Affinidi-hosted VTA: pins PCR0, verifies attestation, and installs your admin credential in one step. |
| pnm bootstrap request / open | The two-step flow for provisioning any other credential (an application credential, a rotated admin key): request generates the bundle, open decrypts it locally. |
| Trust Task | The internal request format every VTA operation dispatches as, whether it arrives over REST, DIDComm, or the vta-mcp bridge. |

## PNM CLI basics

| Term | Meaning |
| --vta <vta-slug> | The global flag telling PNM which VTA to target. Required once more than one VTA is registered, since only the first one becomes the default. |
| JWT | JSON Web Token ([RFC 7519](https://www.rfc-editor.org/rfc/rfc7519)): a compact, signed token carrying claims (who it’s for, when it expires), verifiable without a database lookup. |
| Session token (bearer token) | The short-lived JWT PNM authenticates with. pnm auth show-token prints it, for pasting into a tool that needs a bearer credential. Scoped to one VTA. |
| pnm auth status | Shows whether PNM has a stored session and, if so, for which identity. |

## Next steps

  [Create your first context and signing key](/products/affinidi-elements/vta/get-started/create-your-first-context.md)

  [Security model](/products/affinidi-elements/vta/concepts/security-model.md)