> ## Documentation Index
> Fetch the complete documentation index at: https://docs.openpayload.io/llms.txt
> Use this file to discover all available pages before exploring further.

# What is an OpenPayload DID?

> Understand OpenPayload identities before making your first API request

An OpenPayload DID is a public identifier that belongs to a person, application, device group, service, or automated agent.

“DID” means **decentralized identifier**. Unlike an account number assigned by one website, a DID is controlled through cryptographic keys. An OpenPayload Directory lets other network participants discover the public information associated with that identifier.

You do not need previous blockchain or cryptography experience to use the read-only Directory endpoints.

## The shape of a DID

An OpenPayload DID looks like this:

```text theme={null}
did:openpayload:1111111111111111111111
│   │       └─ unique Base58 identifier
│   └───────── platform or network name
└───────────── tells software this value is a DID
```

The canonical form is `did:<platform>:<Base58Address>`. The platform is 1–32 lowercase ASCII letters or digits. The Base58 address is 16–96 characters using the Bitcoin Base58 alphabet.

`openpayload` is the default platform name, but compatible operators may choose another valid platform name. Preserve the complete identifier exactly when storing, comparing, signing, or sending it to an API.

When a DID appears inside a URL path, URL-encode it:

```text theme={null}
did%3Aopenpayload%3A1111111111111111111111
```

Most HTTP libraries can perform this encoding for you.

## What a DID and its related records can contain

Directory reads associated with a DID can return:

* Public verification keys used to check signatures
* Key-agreement keys used by clients when encrypting messages
* Service endpoints, such as compatible Relay, Cache, or Archive nodes
* Public aliases that are easier for people to recognize
* Registered devices and their lifecycle state
* Delivery constraints and an optional DID-scoped policy through their dedicated endpoints
* Version and update information
* Whether the identity has been deactivated

None of these fields contains the DID controller's private key.

<Card title="See a complete messaging DID document" icon="file-code" href="/concepts/complete-did-document">
  Follow every relationship between verification keys, encryption keys, Relay discovery, and Cache authorization in one example.
</Card>

## Common uses

You might resolve a DID before you:

1. Encrypt a message for its recipient.
2. Verify that a signed message came from the claimed sender.
3. Find a compatible Relay, Cache, or Archive service.
4. Check whether a device is active.
5. Display a public alias.
6. Decide whether the identity is still active.

## DID URLs and key identifiers

A public key inside a DID document usually has an identifier formed by adding a fragment:

```text theme={null}
did:openpayload:1111111111111111111111#root
```

The portion after `#` identifies a component inside the DID document. The complete value is called a **DID URL**. Do not remove the DID portion when passing a key identifier to an authorization endpoint.

## What a Directory does

A Directory is a public gateway to OpenPayload identity data. It reads public state and accepts properly authorized updates. It does not need your private key and should never ask for it.

<CardGroup cols={2}>
  <Card title="Complete DID document" icon="file-code" href="/concepts/complete-did-document">
    See a messaging-ready document with Relay, Cache, and Archive services.
  </Card>

  <Card title="Resolve a DID" icon="magnifying-glass" href="/api-reference/directory/dids/resolve">
    Read a complete public record step by step.
  </Card>

  <Card title="Understand authorization" icon="signature" href="/guides/authorization">
    Learn how nonces, payloads, and signatures work.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.