Glossary

Terms used throughout the WebVH Hosting documentation, Affinidi Portal, and the pnm CLI.

WebVH Hosting stores, validates, and publicly serves the did:webvh identifiers your Verifiable Trust Agent (VTA) creates and signs. You manage it with the Personal Network Manager (PNM), the pnm CLI.

Core concepts

TermMeaning
WebVH HostingThe service that hosts did:webvh identifiers: it validates each signed log, stores it, and serves it at the DID’s public URL. Overview →
ApplianceAn Affinidi-hosted WebVH Hosting instance that you create in Affinidi Portal and Affinidi runs for you.
Hosting serverAny WebVH Hosting deployment: an Affinidi-hosted appliance, or a self-hosted unified daemon or set of standalone services.
VTAVerifiable Trust Agent: holds the keys for your DIDs and signs every version of their logs. VTA →
PNMPersonal Network Manager: the pnm CLI you use to register the appliance and create and manage DIDs through your VTA.
VTA slugPNM’s short local name for a VTA, passed with --vta <vta-slug>.
Super adminA VTA admin with no context restriction. Creating a top-level context requires it.
ContextAn isolated namespace in your VTA. A DID’s keys live in the context it was created in. Manage the contexts on a VTA →

DIDs

TermMeaning
DIDDecentralised Identifier: a W3C standard identifier that resolves to a document of its own keys and endpoints.
did:webvhA DID method whose full history lives in a signed log served from a web address, so anyone can verify every change back to the DID’s creation. Specification →
DID log (did.jsonl)The signed, append-only file that records every version of a did:webvh DID, one JSON entry per line.
SCIDSelf-certifying identifier: the part of a did:webvh DID derived from its first log entry, which ties the DID to its history.
PathThe part of a hosted DID after the domain, such as my-service. You choose it with --path, or the appliance generates a two-word path.
Hosted DIDA DID whose log is stored and served by WebVH Hosting. When your VTA creates it, the VTA’s DID is recorded as its owner.
Pre-rotationCommitting hashes of the next update keys in a log entry, so the following entry must be signed with one of them. Set with --pre-rotation.
Serverless DIDA did:webvh DID your VTA manages without a hosting server. Register it with a server to host it.

Appliance

TermMeaning
Server DIDThe appliance’s permanent DID, a did:webvh, shown on the configuration’s details page in Affinidi Portal. You register it with your VTA using pnm did-mgmt servers add.
Setup DIDA temporary did:key the appliance uses during activation, different from the Server DID. The PNM command in Affinidi Portal gives it a setup admin entry on a webvh context in your VTA, which expires after 6 hours unless the appliance claims it.
WebVH URLThe appliance’s public address, shown on the configuration card in Affinidi Portal. Its host is the domain in every DID you create on the appliance.
Hosting domainThe host a DID resolves from. An appliance serves all its DIDs on its own domain. Hosting domains →
Server IDPNM’s short local name for a registered appliance, such as my-webvh, passed with --server.
Deployment stateThe provisioning status shown in Affinidi Portal: Pending, In Progress, then Complete, or Failed.
Setup StateThe appliance’s activation status in Affinidi Portal: Inactive until activation completes, then Active.
Control planeThe service that receives signed logs from your VTA, validates and stores them, and syncs them to edge servers.
Edge serverThe service that serves each DID’s log and agent-name redirects at the DID’s public URL.

Resolution and names

TermMeaning
ResolveFetch a DID’s log from its public URL and verify it. For a hosted DID, the URL is https://<domain>/<path>/did.jsonl.
Agent nameA short name such as alice, bound to a hosted DID so that /@alice redirects to it. Give a DID a human-readable name →
alsoKnownAsThe DID document field that lists a DID’s agent names. A name resolves only while the document lists it.
Parked nameAn agent name taken out of service but still reserved to its DID.
MediatorA DIDComm v2.1 relay service with its own DID. Add it as a service endpoint in a DID with --mediator-service to make the DID reachable over DIDComm.

Next steps