Specification and Ecosystem Reality
The W3C Decentralized Identifiers Specification reached Recommendation status as DID Core 1.0 and is a widely referenced identifier framework in self-sovereign identity (SSI) and verifiable-credential ecosystems. 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 is Microsoft's implementation of the Decentralized Identity Foundation's Sidetree protocol, anchored to Bitcoin, to deliver a 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 treats key management as out of scope and leaves it to the implementing 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
As disclosed in Application 19/388,580, the keyless-identity primitive expresses identity as a trust slope: the cumulatively validated sequence of Dynamic Agent Hashes (DAH) or Dynamic Device Hashes (DDH) formed by successive, verifiable identity mutations, rather than as a static credential. Each step is computed from the immediately prior step and a source of non-exported unpredictability, derived from a static hardware anchor combined with a per-epoch volatile salt, from a stability-tuned local state vector processed by a strong extractor, or from a hybrid that concatenates both. A receiver stores any previously trusted step and evaluates a presented successor against policy-bounded continuity checks. Because each step binds to the prior step and to non-exported unpredictability, an actor lacking the device's local state or volatile salt cannot feasibly synthesize valid successors. Nothing on the device persists that, if extracted, would let an attacker reproduce the principal's identity off-device.
This is the controller-side substrate the DID specification assumes but does not supply. Where a DID Document publishes a verification method, keyless-identity provides a proof procedure that a claimant satisfies by presenting an on-slope successor of a previously trusted state, validated locally against stored lineage and policy, without materializing a stored private key for the verifier, or for any attacker, to recover. Acceptance is tied to behavioral and continuity integrity: predictive verification forecasts expected successors and bounds acceptable drift, and header-level DAH rotation with forward links constrains long-range linkability while preserving verifiable continuity. The "no stored keys, no stored certificates" property is the architectural distinction; it is a structural property of the primitive, not a configuration convenience.
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. did:key is a special case: because that method encodes the public key directly in the identifier and resolves deterministically to it, keyless-identity composes there through an adjacent method (for example did:web or a new keyless method) whose DID Document references a keyless verification-method type, rather than by altering did:key itself. 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. The specific verification-method registration and proof format are implementation choices left open here; a skilled implementer can bind the trust-slope proof procedure to the DID Document's verification-method surface using the update-rule and continuity mechanisms described above.
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 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 stored-key custody is most costly, fleet devices, autonomous agents, industrial IoT, machine-to-machine credentialing, and large-scale citizen wallets where seizure resistance matters, are exactly the classes where key custody is the binding constraint rather than an incidental detail. Across the ecosystem, secure-element bindings, threshold key splitting, and hardware-backed or cloud-mediated key rotation are common approaches to reducing custody exposure. These are engineering mitigations of stored-key risk; they do not remove the requirement that the controller hold and operate persistent key material.
A keyless controller substrate changes what that layer requires: proof of control by trust-slope continuity rather than by custody of a stored secret. The specification's existing methods, resolvers, and credential formats retain their value; what a keyless controller layer adds is a device-class or agent-class controller surface that the specification assumes but does not itself define. This positioning is an architectural comparison, not a claim about any specific vendor's roadmap or adoption metrics.
Licensing Implication
W3C DIDs are an open specification; no vendor licenses the identifier scheme. The keyless-identity primitive operates one layer below: it is a candidate substrate that satisfies the controller-side proof surface the specification assumes. Implementers of did:web, did:ion, did:peer, and emerging methods can adopt the primitive as verification-method backing without modifying the DID specification itself or fragmenting the resolver ecosystem.
The W3C specification continues to define identifiers and resolution; the primitive supplies what the specification requires but deliberately leaves outside its scope. The relationship is composition rather than competition: DIDs name controllers, and the keyless substrate is a way for the controller to prove control without holding a persistent keypair.
Embodiments and Variations
The keyless-identity approach admits multiple embodiments, each disclosed in Application 19/388,580 and each composable with the DID controller layer above. Per-step unpredictability can be sourced from a static hardware anchor (TPM, TEE, or SoC identifier) combined with a per-epoch volatile salt, from a stability-tuned local state vector processed by a strong extractor, or from a hybrid concatenating both, so both constrained devices and richer platforms are accommodated. Message binding can operate at two stages, screening a transport-header hash for continuity before decryption and validating an embedded successor after decryption. Long histories can be compacted with append-only lineage logs, per-entry commitments, and periodic anchors, enabling sparse and delayed verification from bounded proof windows for intermittent, high-latency, or disconnected links. Agent-side mutations can be entangled to the executing host's device identity to yield verifiable cross-substrate provenance. Recovery after memory loss can proceed by quorum attestation from previously trusted peers rather than by restoring a stored secret. Entropy anchors can rotate proactively or reactively with forward links, and biometric-assisted reseeding via privacy-preserving fuzzy extractors with liveness verification can supply additional local unpredictability without ever storing or exporting raw biometric data. A legacy-bridge adapter can interoperate with PKI-based counterparties through a segregated, session-scoped identifier that never contaminates trust-slope formation. A skilled implementer can build the controller layer from these mechanisms and bind it to the DID Document verification-method surface without altering DID resolution.
Disclosure Scope
The invention described here, memory-native identity and authentication that proves control through trust-slope continuity rather than through a stored keypair, is disclosed in United States Patent Application 19/388,580. This article is a dated public description of that inventive step and its embodiments. All statements in it about the invention's mechanisms, primitives, and properties refer to that disclosure.
References to W3C Decentralized Identifiers (DID Core 1.0), DID Resolution, the Universal Resolver, the Verifiable Credentials Data Model, specific DID methods (did:key, did:web, did:ion, did:peer), and related ecosystem and market context are provided as external technical framing to situate the comparison. They describe third-party standards and initiatives accurately at the architecture level and are not claims of Application 19/388,580, nor an assertion of any affiliation with, or endorsement by, the W3C, the Decentralized Identity Foundation, or any named implementer. Where a characterization of the external ecosystem could not be stated as a widely established architectural fact, it has been scoped to a neutral, general statement.
