W3C Decentralized Identifiers (DIDs)
by Nick Clark | Published April 25, 2026
W3C Decentralized Identifiers (DID Specification 1.0, ratified as a W3C Recommendation) define a portable identifier scheme — did:key, did:web, did:ion, did:peer, and adjacent methods — resolved through DID Resolution and the Universal Resolver. The specification defines the identifier surface; the keyless-identity primitive provides the stateless device-level substrate the specification assumes but does not itself supply.
Specification and Ecosystem Reality
The W3C Decentralized Identifiers Specification reached Recommendation status as DID Core 1.0 and stands as the canonical identifier framework for self-sovereign identity (SSI), verifiable-credential ecosystems, and the EU eIDAS 2.0 European Digital Identity Wallet trajectory. A DID is a URI of form did:method:method-specific-id, paired with a DID Document that publishes verification methods, service endpoints, and controller relationships. The DID Document is the resolution target; the DID itself is the stable, controller-portable handle.
The method surface is heterogeneous by design. did:key embeds a public key directly in the identifier and resolves deterministically without external infrastructure — the simplest method, suitable for ephemeral or local use. did:web anchors the DID Document at a conventional HTTPS location under a domain, trading decentralization for operational familiarity. did:ion uses Microsoft's Sidetree protocol over Bitcoin to deliver a scalable, late-binding ledger-anchored method. did:peer is designed for pairwise relationships where the DID never appears in a public registry. DID Resolution, defined in a companion W3C specification, governs how a DID URI is dereferenced into its document; the Decentralized Identity Foundation's Universal Resolver provides a multi-method reference implementation that brokers across method drivers. The ecosystem assumption — uniform across every method — is that the controller of a DID holds and operates the cryptographic key material referenced in its DID Document.
Architectural Gap
The DID specification is rigorous about identifiers and silent about how the controller actually holds keys. Every production DID method assumes the controller maintains private-key material — in a secure element, an HSM, a hardware wallet, a TPM-backed keystore, or a software wallet — and that operations like authentication, assertion, and key rotation flow from continuous custody of those keys. The specification leaves key custody to "the controller's environment," which in practice means each DID method ecosystem reinvents the same hard problem: how does a device-class principal prove control of a DID without becoming a long-term custodial liability?
For deployment classes where the controller is a fleet device, an autonomous agent, an IoT sensor, or an industrial endpoint, persistent key storage is exactly the wrong primitive. Stored keys are seizable, exfiltrable, and a chain-of-custody hazard across firmware updates, device resale, and decommissioning. Certificate-based alternatives reintroduce PKI custody at a different layer. The DID specification cannot close this gap because the gap is below its layer: DIDs name controllers and publish verification methods, but something else has to be the controller without holding stored secrets. Until that something exists as a distinct primitive, every DID method ecosystem either accepts the custody hazard or pushes it onto the deployer.
What the Keyless-Identity Primitive Provides
The keyless-identity primitive provides stateless device pseudonymity as an architectural substrate. A device-class principal participates in identity-bound operations without storing keys, certificates, or any long-lived credential artifact. Authentication derives statelessly from a combination of device-intrinsic factors and protocol-level challenge structure; nothing on the device persists that, if extracted, would reproduce the principal's identity off-device.
This is the substrate the DID specification assumes but does not supply. Where a DID Document publishes a verification method, keyless-identity provides the controller-side surface that satisfies the verification method without ever materializing a stored private key for the verifier — or for any attacker — to recover. The pseudonymity is stable: the principal is consistently re-identifiable across sessions to authorized verifiers, while remaining unlinkable across observation contexts that lack the verification credential. The "no stored keys, no stored certificates" property is the architectural distinction; it is not a UX convenience but a structural property of the primitive.
Composition Pathway
Composition with W3C DIDs is method-aligned rather than method-replacing. A DID controlled by a keyless-identity principal publishes a DID Document referencing a verification method whose proof procedure is satisfied by the keyless substrate. For did:key, the embedded public-key form is replaced by a verification-method type that derives non-interactively from the principal's stateless identity surface. For did:web, the DID Document is hosted conventionally but its referenced verification method invokes the keyless primitive at proof time. For did:ion and did:peer, the same pattern applies at the method's anchoring and pairwise-exchange layers respectively.
DID Resolution and the Universal Resolver continue operating unchanged: they resolve identifiers to documents, and the documents reference a verification-method type that the keyless-identity primitive satisfies. Verifiable Credentials issued under the W3C VC Data Model bind to the DID, and the holder's proof-of-control flows from the keyless substrate rather than from custody of a stored key. The composition leaves the DID specification's identifier and resolution surfaces fully intact; what changes is that the controller layer the specification assumed becomes a primitive the DID Document can reference rather than a custody responsibility the deployer must reinvent.
Commercial Trajectory
The deployment classes where DIDs have struggled most — fleet devices, autonomous agents, industrial IoT, machine-to-machine credentialing, and large-scale citizen wallets where seizure resistance is non-negotiable — are exactly the classes where stored-key custody is the binding constraint. Wallet-software vendors, EU EUDI Wallet implementers, supply-chain credentialing platforms, and IoT-identity startups have each independently produced custody-mitigation layers (secure-element bindings, threshold key splitting, cloud-mediated rotation) without solving the underlying primitive problem.
Keyless-identity available as a primitive collapses that work into a substrate every DID method can reference. The commercial trajectory for the DID ecosystem improves on the axis where adoption has been slowest: deployments in which the controller is a device or agent rather than a human user with a managed wallet. The specification's existing methods, resolvers, and credential formats retain their value; what becomes newly tractable is the device-class controller surface that the specification has always assumed but never produced.
Licensing Implication
W3C DIDs are an open specification; no vendor licenses the identifier scheme. The licensing implication operates one layer below: the keyless-identity primitive is the substrate that satisfies the controller-side surface the specification assumes. Implementers of did:key, did:web, did:ion, did:peer, and emerging methods can adopt the primitive as the verification-method backing without modifying the DID specification itself or fragmenting the resolver ecosystem.
For ecosystem participants — wallet vendors, credential issuers, EUDI Wallet implementers, IoT-identity platforms — licensing keyless-identity converts a custody-engineering burden each has been carrying independently into a shared substrate the DID Document can reference. The W3C specification continues to define identifiers and resolution; the primitive supplies what the specification has always required but deliberately left outside its scope. The result is composition rather than competition: DIDs name controllers, and keyless-identity is what the controller is.
