Identity

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.

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

ActorIdentityDID method
The VTA itselfVTA DIDdid:webvh
Whoever administers the VTAAdministrator DIDdid:key
Each application you provisionApplication DIDdid:key
A mediator, AI agent, or similar integrationIntegration DIDUsually did:webvh

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.

VTAone identity per actorVTA DIDAdministrator DIDApplication DIDIntegration DIDResolved externally,verifies who signed.These identities call the VTA.Its ACL decides what each may do.One DID is the VTA's own identity that others verify signatures with.The other three are caller identities the ACL checks to grant access.

VTA DID

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

  • Affinidi-hosted: always 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 any DID resolver, not just Personal Network Manager (PNM), can find the VTA’s REST URL or DIDComm mediator automatically. 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 a key rotation is something anyone can verify happened, not just be told about.

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. This only comes up on a self-hosted VTA set up for local development. 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. 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.
  • Affinidi-hosted: the VTA mints it for you, inside the Trusted Execution Environment, during the attested bootstrap, generated automatically as part of that single step.

  Deploy an Affinidi-hosted VTA

  Self-hosted deployment