Decentralised Identifier (DID)

Expanded Definition

A Decentralised Identifier, or DID, is a globally unique identifier that can be resolved to a DID Document containing public keys, service endpoints, and verification methods. In NHI security, the important distinction is that the identifier is not issued or controlled by one central authority.

That architecture matters because AI agents and other machine identities increasingly need portable identity across cloud tenants, partner ecosystems, and orchestration layers. The W3C DID Core specification defines the technical model, while implementation patterns still vary across vendors and ecosystems, especially where verifiable credentials, wallet models, and trust registries are involved. For that reason, definitions vary across vendors when DID is discussed as a full identity stack versus only an identifier and resolution mechanism.

A DID is not a replacement for authentication, authorisation, or lifecycle governance. It is the identity anchor that can support those functions when paired with keys, policy, and revocation controls. The most common misapplication is treating a DID as proof of trust by itself, which occurs when teams resolve an identifier but never validate issuer policy, key binding, or agent lifecycle state against a governance framework such as NIST Cybersecurity Framework 2.0.

Examples and Use Cases

Implementing DIDs rigorously often introduces lifecycle and interoperability overhead, requiring organisations to weigh portable identity against the cost of key management, resolution infrastructure, and trust governance.

• An autonomous AI agent uses a DID to present a stable identity to multiple SaaS tools while its signing keys rotate behind the scenes.
• A vendor-supplied workload proves its identity in a partner environment without relying on a shared directory or static API key, reducing the blast radius of credential theft.
• A platform team binds a DID to a verifiable credential that asserts agent role, ownership, and allowed actions before granting tool access.
• An incident responder reviews a suspicious token chain and finds that the original compromise was enabled by exposed secrets, similar to the patterns discussed in JetBrains GitHub plugin token exposure.
• A zero trust program uses DIDs as one input to workload trust decisions, but still requires policy enforcement, attestation, and continuous verification aligned to NIST Cybersecurity Framework 2.0.

In practice, DIDs are most useful where identity must survive cloud boundaries, supply chain relationships, and agentic workflows without depending on one central registry to stay online or authoritative.

Why It Matters in NHI Security

DIDs matter because machine identity failures rarely begin with the identifier itself. They begin when long-lived secrets, unmanaged keys, or weak binding logic turn a supposedly portable identity into an exposed credential path. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why DID-based models are often evaluated alongside secret reduction and key lifecycle controls rather than in isolation.

For AI agents, DIDs can improve auditability and cross-domain trust, but only if the surrounding control plane handles provisioning, revocation, and verification consistently. Otherwise, a DID may give the appearance of decentralised trust while the real attack surface remains in unmanaged keys, stale credentials, or missing owner attribution. This is especially relevant in environments already struggling with secrets sprawl, as documented in JetBrains GitHub plugin token exposure and in broader identity governance guidance from NIST Cybersecurity Framework 2.0.

Organisations typically encounter the operational consequences only after an agent is compromised, a partner trust relationship is abused, or an identity has to be revoked mid-incident, at which point DID governance becomes operationally unavoidable to address.