Standard and Ecosystem Reality

The W3C Verifiable Credentials Data Model 2.0 became a W3C Recommendation in 2025, and the Decentralized Identifiers (DIDs) 1.0 specification reached Recommendation status in 2022. Together they define a triangle of roles, issuer, holder, verifier, and a serialization-flexible data model that supports both JSON-LD with Linked Data Proofs and JSON Web Token VCs (JWT-VC and SD-JWT-VC). The data model is deliberately credential-agnostic: a VC may carry an academic transcript, an employment claim, a mobile driver's license under ISO/IEC 18013-5, or an EU Digital Identity Wallet attestation under eIDAS 2.0.

The ecosystem around the standards is substantial. Hyperledger Indy and Aries supply ledger and agent infrastructure. Indicio, Spruce, Mattr, Trinsic, and Microsoft Entra Verified ID supply commercial issuance and wallet stacks. The European Union's EUDI Wallet Architecture and Reference Framework treats VCs and SD-JWTs as first-class credential formats. The U.S. Department of Homeland Security Silicon Valley Innovation Program has funded VC integration across CBP, USCIS, and TSA pipelines. The standard is real, the deployment surface is real, and the regulatory tailwind is real.

Architectural Gap

The VC and DID architecture assumes a holder controls a private key, typically held in a wallet, a TEE, or a hardware security module, and that authentication of the holder to the wallet, and of the wallet to the device, is solved out of band. In the predominant deployment pattern this means biometrics or PINs unlocking a key store, with the keys themselves persistent on the device. Three structural problems follow.

First, key compromise is catastrophic and recovery is operationally heavy: revocation lists, status credentials (Bitstring Status List), and re-issuance flows handle the failure mode but do not eliminate the persistent-key assumption. Second, device-bound credentials cannot be cleanly transferred or rotated across hardware without re-issuance, which is friction at fleet scale and a privacy hazard at consumer scale. Third, the wallet itself becomes the attack surface: a compromised wallet exposes every credential it holds, and biometric unlock becomes an irreversible disclosure if the biometric template leaks. None of this is a defect in the W3C specifications: they are explicit about leaving key management out of scope. It is, however, the architectural gap that determines whether VC deployments survive contact with adversarial environments and high-volume device fleets.

What Keyless Identity Provides

Keyless Identity, as disclosed in United States Patent Application 19/388,580, expresses identity as a trust slope: a cumulatively validated sequence of Dynamic Agent Hashes (DAH) or Dynamic Device Hashes (DDH), each computed as a successor of the immediately prior trusted state under an update rule that incorporates a source of local, non-exported unpredictability and a volatile salt. That unpredictability is drawn from one of three enabled sources: a keyed derivation from a static hardware anchor (for example a TPM, TEE, or SoC identifier) combined with a per-epoch volatile salt; an extractor output over a stability-tuned local state vector of device-observable signals such as timing jitter, scheduler statistics, and I/O micro-variation, computed without exposing the raw state; or a hybrid that concatenates both. A verifier accepts a presented successor by reconstructing the expected successor from its last trusted state and checking on-slope continuity under policy-bounded parameters. There is no persistent private key, no stored certificate, and no raw biometric template retained on the device; where the disclosure contemplates biometrics at all, it is an optional biometric-assisted reseeding path through a privacy-preserving fuzzy extractor with liveness verification, whose seed is never stored or exported in raw form.

Three architectural properties matter for VC composition. First, no exfiltrable standing secret: because each DAH/DDH is ephemeral and never reused as a credential, a device seized, imaged, or cloned at rest yields no long-lived key that can impersonate the holder in a future session, and observing any single hash does not enable forging a successor without the device's local unpredictability. Second, no stored biometric template: the substrate does not require the holder to deposit an irrevocable biological identifier on the device. Third, continuity that survives hardware rotation: entropy-anchor rotation with recorded forward links, and quorum-based recovery using attestations from previously trusted peers, let a holder re-anchor a slope after device loss or memory loss without a persistent key registry. The substrate does not replace the VC data model or the DID resolution layer; it replaces the holder-binding and key-management substrate underneath them.

Composition Pathway

Composition with W3C VC and DID architecture is structural. The VC remains the credential object: a JSON-LD or SD-JWT VC with the same issuer, subject, claims, and proof structure that the data model already defines. The DID remains the identifier surface: a did:web, did:key, did:ion, or did:peer continues to anchor the subject. What changes is the binding between the holder and the proof. Rather than the holder presenting a signature produced by a stored private key, the holder presents a successor DAH on its trust slope, and the verifier checks on-slope continuity against its last trusted state and policy bounds. In a two-stage arrangement the presented hash is screened in a transport header for fast continuity before any payload is decrypted, and an embedded copy is validated against the sender slope after decryption, so both routing-level and content-level binding are checked.

The path is incremental because the standards leave a clean insertion point. SD-JWT VC presentation flows already separate credential issuance from holder binding via the cnf (confirmation) claim; a keyless holder binding fits as an alternative confirmation mode rather than a fork of the format. JSON-LD VCs with Data Integrity Proofs are designed to admit new proof suites, so a keyless proof suite is an additive registration, not a change to the data model. Because the VC object and the OpenID4VP presentation exchange are unchanged, a wallet that adopts this substrate can retain its existing issuance and presentation surfaces and swap only the holder-binding backend. For EUDI Wallet implementations pursuing eIDAS 2.0 high assurance, a keyless binding mode is one way to reach holder binding without depositing a biometric template or a long-lived key on the device.

Commercial Implication

The commercial center of gravity for VC deployments is shifting from issuance tooling, a saturated and increasingly commoditized layer, toward assurance and recovery. A wallet that can credibly claim no persistent stored key and no stored biometric template has a distinct position to argue in both regulatory review (eIDAS 2.0 cybersecurity certification, NIST SP 800-63-4 IAL and AAL evolution) and enterprise procurement (workforce credentialing programs that would rather not carry biometric-template liability). For ecosystem participants building on the W3C stack, a keyless holder-binding substrate is an additive assurance layer that leaves the standards-defined credential and identifier surfaces intact.

For mobile driver's license programs under ISO/IEC 18013-5 and 18013-7, the recurring concern that a phone-resident credential is only as trustworthy as the phone's key store and biometric subsystem is addressed differently when holder binding derives from a validated trust slope rather than a stored key unlocked by a biometric. This is a structural difference in where trust is rooted, not a claim that hardware-backed approaches such as FIDO2 and passkeys are insecure; those bind credentials to a hardware authenticator and resist phishing well. The distinction the substrate draws is narrower: it removes the persistent on-device secret and the stored biometric template from the holder-binding path, which is the specific axis this disclosure addresses.

Licensing Implication

The Keyless Identity substrate is positioned as a licensable architectural layer rather than as a wallet product. The VC and DID standards are royalty-free under W3C policy, and a keyless holder-binding layer does not encumber that surface: the data model, proof formats, and DID resolution remain W3C-governed and unchanged. The subject matter that a license would cover is the trust-slope authentication architecture disclosed in United States Patent Application 19/388,580, the derivation of dynamic device and agent hashes from local unpredictability, and the two-stage validation and no-persistent-key properties, embedded underneath an implementer's existing W3C-compliant VC and DID surfaces. Structuring such a license to permit downstream wallet implementers to integrate without separate negotiation is what would let the substrate propagate across the existing VC ecosystem at the rate the standards themselves propagate.

Disclosure Scope

The invention described here, Keyless Identity, is disclosed in United States Patent Application 19/388,580. The claims about what this substrate does, identity as a validated trust slope of Dynamic Agent Hashes and Dynamic Device Hashes derived from a hardware anchor with a volatile salt, a stability-tuned local state vector processed by a strong extractor, or a hybrid of both; two-stage header-and-payload validation; append-only entanglement lineage with periodic anchors; delayed and sparse validation from bounded proofs; predictive drift detection; entropy-anchor rotation with forward links; quorum-based recovery after memory loss; optional biometric-assisted reseeding via a privacy-preserving fuzzy extractor; and isolated fallback interoperability with legacy PKI, are grounded in that application.

Embodiments contemplated by the disclosure span stateless execution fabrics, intermittently connected and delay-tolerant networks, memory-constrained IoT and embedded endpoints, decentralized and cross-domain federations, and cognition-native agent platforms, with identity sourced from a hardware anchor, from a local state vector, or from a hybrid, and validation proceeding locally without centralized authorities, long-lived keypairs, or synchronized registries. A skilled implementer can build the approach from the update rule, extractor, continuity checks, and lineage structures the specification describes.

The remaining framing in this article, the description of the W3C Verifiable Credentials Data Model 2.0, the DID 1.0 specification, the SD-JWT VC and JSON-LD proof formats, the EUDI Wallet and eIDAS 2.0 context, the ISO/IEC 18013-5 and 18013-7 mobile driver's license programs, the named ecosystem implementers, and the market and regulatory observations, is external context describing standards and products maintained by their respective organizations. Those descriptions are provided for comparison only and are not claims of United States Patent Application 19/388,580.