Decentralized Identity and DIDs
Decentralized Identity and DIDs
- Understand the basic principal, delegate, verifier, and mandate vocabulary from the Foundations lesson.
- explain why durable identifiers matter for delegated authority
- describe how DID subjects, DID documents, and verification methods relate
- connect identity representation to Mandaitor mandates and verifiers
Digital identity begins with a simple question: how does a system know which actor it is dealing with? In ordinary applications, the answer may be an email address, username, account ID, service account, API key, or identity-provider subject. Those identifiers are useful, but they are often tied to one provider, one database, or one application boundary.
Decentralized identifiers, or DIDs, provide a different mental model. W3C DID Core defines DIDs as identifiers that enable verifiable, decentralized digital identity, and a DID can refer to any subject, including a person, organization, thing, data model, or abstract entity.1 A DID is associated with a DID document, which can express verification methods, services, and cryptographic material that help others verify control or interact with the subject.1
Mandaitor learners do not need to become DID protocol experts immediately. They need to understand why persistent, verifiable identity matters when agents act on behalf of people and organizations.
Why identity becomes harder with agents
A normal user login tells an application that a human session exists. An agentic workflow introduces more actors. There may be a human principal, a company tenant, a model provider, an agent runtime, a tool client, a workflow instance, a service account, and a downstream API. If all of those are collapsed into one API key, authority becomes difficult to explain.
| Identity question | Why it matters for Mandaitor |
|---|---|
| Who is the principal? | Mandates must identify whose authority is being delegated. |
| Who or what is the delegate? | Verification must distinguish one agent, service, or workflow from another. |
| Which key or method proves control? | Verifiers need a way to connect requests to the right identity material. |
| Can identity survive account or key rotation? | Long-lived evidence should not break when operational credentials change. |
| Which service endpoint represents the actor? | Integrations may need discovery or metadata without hard-coded assumptions. |
The DID mental model
A DID is like a durable pointer to an identity subject. The DID document is the structured description that tells verifiers how to interact with or verify that subject. This separation is important because an identifier can remain stable while verification methods rotate over time.
| DID concept | Plain-language meaning | Mandaitor learning value |
|---|---|---|
| DID subject | The entity identified by the DID. | Principal, organization, agent, service, or authority object. |
| DID controller | The entity that can update or control the DID document. | The party responsible for maintaining verification methods. |
| DID document | The machine-readable document connected to the DID. | Where verification methods and service metadata can be found. |
| Verification method | A way to verify control or signatures. | How proof material can be connected to an identity. |
| Service | A described interaction endpoint. | How relying systems may discover related capabilities. |
Agent identity in Mandaitor terms
Mandaitor can use DID-inspired thinking even when a concrete deployment integrates with conventional identity providers. The critical point is to make agents and delegates identifiable as first-class subjects. A named agent should not disappear behind a generic backend token. It should have an identity that can be bound to mandates, audit events, and evidence packs.
| Mandaitor concern | DID-inspired design principle |
|---|---|
| Agent registration | Give the agent a stable subject rather than treating it as anonymous automation. |
| Key rotation | Allow verification material to change without rewriting historical identity. |
| Evidence review | Preserve identity references that can be understood after credentials rotate. |
| Multi-tenant boundaries | Keep organizational and agent identities clearly scoped. |
| Delegation chains | Make it possible to reason about who delegated to whom. |
Agent identity profile: DID, verification methods, and runtime binding
This structured registry view shows how a stable agent identity becomes useful only when it is connected to verification material, mandates, runtime context, and evidence.
| Registry field | Example value | Why a verifier cares |
|---|---|---|
| Agent subject | Finance Operations Assistant | Gives the delegate a human-readable identity instead of hiding it behind an API key. |
| Stable identifier | did:web:agents.example#finance-ops | Lets mandates and evidence refer to the same subject across key rotation. |
| Verification method | key-2026-05-ed25519 | Shows which key material can prove control for current requests. |
| Runtime binding | workflow:payment-request-review | Connects identity to the operational environment that performs actions. |
| Linked mandates | payment_request.create below threshold | Makes delegated authority inspectable from the identity surface. |
| Evidence stream | audit_events.finance_ops | Tells reviewers where decisions involving this agent will appear. |
- Learning cue: the DID is the pointer, the DID document contains verification and service metadata, and Mandaitor policy decides whether a requested action is allowed.
- Reviewer cue: identity registration is not trust by itself; it gives verifiers and reviewers stable material for trust decisions.
DIDs do not remove the need for trust decisions
A DID can help a verifier find verification material, but it does not automatically prove that a mandate should be accepted. A relying system still needs to decide whether it trusts the issuer, whether the DID method is appropriate, whether the key is current, whether the proof is valid, and whether the business policy allows the action.
| Misunderstanding | Better interpretation |
|---|---|
| A DID is the same as a verified real-world identity. | A DID identifies a subject and can support verification, but trust depends on context and governance. |
| A DID replaces authorization. | Identity helps establish who is involved; authorization still checks what may be done. |
| A DID document never changes. | Verification methods and services may rotate or evolve while the identifier remains stable. |
| Any DID should be accepted. | Verifiers must decide which issuers, methods, controllers, and policies they trust. |
What to read next
Continue with Verifiable Credentials, Claims, and Proofs to learn how claims can be issued and presented. Then read Trust Chains and Credential Verification to understand how identity, issuer trust, proof status, and policy come together in a verification decision.
Save your learning progress
Mark this lesson as complete to update the Academy overview without requiring an account.