# 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)](https://www.w3.org/TR/did-core/): 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

| Actor | Identity | DID method |
| The VTA itself | VTA DID | did:webvh |
| Whoever administers the VTA | Administrator DID | did:key |
| Each application you provision | Application DID | did:key |
| A mediator, AI agent, or similar integration | Integration DID | Usually did:webvh |

Contexts aren’t in this table: a context is a namespace, not an identity. See [Keys and contexts](/products/affinidi-elements/vta/concepts/keys-and-contexts.md#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.

Note

An integration like a mediator or AI agent actually has two DIDs, not one: the public identity shown above, plus a separate did:key credential that holds the ACL authority to manage it. See [Sign application payloads without exposing your keys](/products/affinidi-elements/vta/integration-guides/provisioning-app-signing.md) for how a plain application gets its own credential.

## 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:

```text
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:

```text
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](/products/affinidi-elements/vta/get-started/self-hosted.md#step-2-generate-your-administrator-did) 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](/products/affinidi-elements/vta/concepts/security-model.md#trusted-execution-environment-tee), during the attested [bootstrap](/products/affinidi-elements/vta/get-started/vta-affinidi-portal.md#step-3-bootstrap-pnm-against-the-vta), generated automatically as part of that single step.

Important Note

On a self-hosted VTA, PNM generates the private key locally; only the public did:key is embedded in the setup file, so the VTA never holds it. On an Affinidi-hosted VTA, the VTA generates the private key for you inside the enclave and seals it to your machine in the bootstrap response, so only you can open it.

## Related

  [Deploy an Affinidi-hosted VTA](/products/affinidi-elements/vta/get-started/vta-affinidi-portal.md)

  [Self-hosted deployment](/products/affinidi-elements/vta/get-started/self-hosted.md)