Identity

If a VTA just handed out signatures and secrets without any identity attached, verifying who actually signed something, or who is administering the VTA, would mean trusting the operator’s word for it. A VTA avoids that by giving every actor in the system its own Decentralised Identifier (DID): a cryptographic identity any third party can resolve and check independently, not an opaque database row only the VTA itself can vouch for.

Identities in the system

Contexts aren’t in this table: a context is a namespace, not an identity. See Keys and contexts.

The VTA DID is what a third party resolves to verify a signature came from this VTA. Every other DID in this table is what the VTA’s own access control list (ACL) checks to decide what that caller is allowed to do.

VTA DID

A VTA mints its own DID once, at setup. Which method it uses depends on where it runs:

• Affinidi-hosted: did:webvh, set automatically when Affinidi provisions the appliance.
• Self-hosted: did:webvh is recommended, and is what every guide on this site uses. did:key is also genuinely available and is a reasonable choice for local development or a quick, throwaway test instance; it just has no hosted history to inspect later.

For example, a did:webvh VTA DID:

did:webvh:QmVE1TQeCtg3aavpTqasqencJpagRr8JKdGRyoZ5Qx6kRp:your-appliance.vta.affinidi.io

did:webvh gives you two things a bare did:key does not:

• A service endpoint. Its document can list one, so a DID resolver, not just Personal Network Manager (PNM), can find the VTA’s REST URL or DIDComm mediator from the document when the VTA advertises them. A did:key document is a fixed structure derived only from the public key, so it has no room for a service endpoint the way a hosted document does.
• A public history. Its document is a log, not a snapshot, so anyone who can fetch the published log can verify that a key rotation happened, rather than just being told about it.

Both matter most for a stable, long-lived identity. Neither matters much for a local development instance you’ll tear down anyway, which is why self-hosted setup still offers did:key as a quick-start option.

VTA URL

The public REST endpoint of the VTA. If the VTA’s own DID is did:webvh, PNM resolves this automatically from the DID document. A did:key VTA DID has no service endpoint to discover this way, so you supply the VTA URL explicitly when connecting PNM. You mainly need this for a did:key VTA, or when the VTA’s DID document does not yet advertise a REST URL. For example:

https://example.vta.affinidi.io

Administrator DID

The did:key identity with admin role at a VTA, giving it full control over keys, contexts, delegations, and policies. Affinidi hosts a VTA in one of two modes. Isolated runs in an AWS Nitro Enclave, a Trusted Execution Environment (TEE), with hardware-rooted attestation, keys and data. Shared runs on a shared network, for evaluation and development purposes only. How you get one depends on where the VTA runs:

• Self-hosted: you generate it yourself with pnm setup, before the VTA exists. You embed it directly in the VTA’s setup file, which grants it admin role and seals the VTA in the same step.
• Isolated mode: PNM creates it for you during the attested bootstrap. The VTA first enrols your bootstrap claim DID as a temporary administrator, for up to 24 hours. Once PNM has checked the enclave’s attestation, it creates the Administrator DID on your machine, hands the administrator role over to it, and deletes the claim key.
• Shared mode: you generate it yourself with pnm setup and enter it in Affinidi Portal when you create the VTA. Once the VTA is deployed, pnm setup continue connects PNM and replaces it with a permanent credential.

Related