Decentralized Authentication Layer (dAuth)

• dAuth is a decentralized authentication framework that replaces traditional central authorities with verifiable artifacts like TEE attestation, DID documents, and blockchain records.
• It integrates authentication, authorization, revocation, and auditability into a unified system pattern adaptable for various applications such as IoT, TLS, and smart contracts.
• Practical implementations reveal trade-offs in performance and security, with systems demonstrating measurable latency differences and tailored trust anchoring mechanisms.

A decentralized authentication layer, or dAuth, denotes a class of mechanisms, components, and protocols that allow entities to authenticate without a centralized online intermediary, while shifting trust to cryptographically verifiable artifacts such as TEE attestation evidence, decentralized identifiers, verifiable credentials, blockchain-anchored records, attribute keys, passkey-bound credentials, or biometric commitments. In the literature, dAuth appears both as an explicit architectural term and as an organizing abstraction for systems that combine authentication, authorization, revocation, and auditability without a conventional identity provider or certificate authority (Zheng et al., 2020, Mitra et al., 25 Dec 2025).

1. Design space and representative realizations

The term spans multiple technical lineages rather than a single protocol family. Some realizations place the trust root in trusted hardware and verified code; some in DID documents and issuer signatures; some in blockchain state and smart contracts; and some in privacy-preserving biometric or password-authenticated constructions. A recurring theme is that authentication is coupled to policy state, not merely to possession of a key.

Realization	Representative systems	Primary trust anchor
TEE-centered dAuth	Decent	IAS/DCAP root, enclave code identity, AuthList
DID/VC-centered dAuth	DID Link, DAXiot, AgentDID	DID resolution, issuer keys, VP verification
Password-based decentralized auth	PDIDs	TEE-backed blockchain smart contract
Passkey-based decentralized auth	Verifiable Passkey	Issuer-signed VC, PageX, WebAuthn
Blockchain trust and PKI layers	Authcoin, UAV trust graph, BATM	On-chain challenge records or trust graph
Biometric decentralized auth	BioZero, fuzzy-commitment blockchain biometrics	Commitments, zero-knowledge proofs, blockchain state

In “Building secure distributed applications the DECENT way,” dAuth is realized through reusable self-attestation certificates and application-scoped authorization state, so that components authenticate not only code identities but also the other components they trust (Zheng et al., 2020). In “Verifiable Passkey: The Decentralized Authentication Standard,” dAuth is defined as the combination of issuer, PageX, wallet, authenticator, and verifier that enables authentication “without a centralized online intermediary” (Mitra et al., 25 Dec 2025). DID-centered variants such as DID Link and DAXiot preserve standard transport or messaging substrates while replacing CA-issued or broker-local trust with DID-bound keys and selectively disclosed credentials (Garzon et al., 2024, Philipp et al., 2023).

This variety suggests that dAuth is best understood as a systems pattern: decentralized trust roots, verifiable identity material, explicit authorization semantics, and protocol flows that can be checked by peers or smart contracts rather than by a central identity server.

2. Trust roots, identity material, and chain of authority

The strongest distinction across dAuth designs is the object to which trust is anchored. In Decent, the root of trust is the trusted hardware manufacturer. A Decent Server self-generates a key pair and binds its public key to enclave code identity via a remote-attestation quote, producing a self-attestation certificate that third parties can verify offline. Component certificates then bind a component public key, its code measurement, and an immutable AuthList to that server key, yielding a chain in which verifiers accept a key as a manufacturer-audited enclave key and then check application-scoped policy state (Zheng et al., 2020).

DID-based systems move the trust root from WebPKI or centralized identity providers to DID documents and issuer-controlled key material. DID Link authenticates in TLS 1.3 with self-issued X.509 certificates whose subjectAltName carries a DID, and then verifies that the certificate’s SubjectPublicKeyInfo appears in the DID Document’s verification methods. Identification is completed post-handshake through DID-bound verifiable credentials (Garzon et al., 2024). AgentDID similarly separates an administrative key, used for DID document updates, from an operational key, used for requesting credentials and signing verifiable presentations (Xu et al., 28 Apr 2026).

Other systems bind identity to different scarce or hard-to-forge substrates. PDIDs place the authentication service inside a confidential smart contract, the Global Password Manager, and derive a collision-secure global namespace by enforcing assert users[U] == \bot during registration (Szalachowski, 2020). Blockchain trust-graph systems store identities, public keys, trust relations, or challenge-response records directly on chain, so that authentication becomes path validation over on-chain edges or inspection of publicly recorded validation events (Jäger et al., 2024, Leiding et al., 2016). FlexiChain’s NodeChain binds node identity to tokenized unique identifiers derived from extrinsic device parameters and trusted hardware, while BATM anchors trust events such as credential issuance, blame, ban, and revocation in blockchain payloads with miner-approval rules (Alkhodair et al., 2023, Moinet et al., 2017).

A plausible implication is that “decentralized” does not denote a single replacement for PKI. It denotes a relocation of trust: from a centralized issuer of runtime decisions to cryptographically verifiable state distributed across ledgers, hardware vendors, or multiple attribute authorities.

3. Credential forms and proof mechanisms

The credential vocabulary of dAuth is correspondingly heterogeneous. Decent uses X.509 structures enriched with attestation evidence, local-attestation reports, and immutable AuthLists. The server self-attestation certificate is described by

$$C_S = \big(pk_S \Vert R_S \big),\quad \sigma_S = \mathrm{Sign}_{sk_S}(C_S),$$

while a component certificate includes the component key, code measurement, AuthList, and local-attestation evidence

$$C_{comp} = \big(pk_C \Vert H(\mathsf{code}_C) \Vert AL_C \Vert L_C \big),\quad \sigma_{comp} = \mathrm{Sign}_{sk_S}(C_{comp}).$$

The resulting credential is both an identity artifact and an authorization artifact, because the AuthList is part of the signed object (Zheng et al., 2020).

DID/VC systems typically use DID documents plus verifiable credentials or presentations. DAXiot issues an SD-JWT AuthorizationCredential whose issuer is a did:web, whose subject is a did:key, and whose disclosures selectively reveal broker-specific publish and subscribe topics (Philipp et al., 2023). DID Link uses self-issued X.509 during the TLS handshake and exchanges W3C verifiable credentials after the handshake, with optional selective disclosure through SD-JWT (Garzon et al., 2024). AgentDID formalizes the lifecycle with

$$\Pi_{\mathsf{VC}} = (\mathsf{Request}, \mathsf{Issue}, \mathsf{Present}, \mathsf{Verify}),$$

and binds each presentation to a fresh verifier nonce (Xu et al., 28 Apr 2026).

Verifiable Passkey uses a W3C Verifiable Credential whose credentialSubject embeds passkey metadata such as aaguid, credential_id, public_key, and pagex. The verifier validates the issuer’s signature offline, redirects the claimant to the static PageX origin, and then checks a standard WebAuthn challenge–response against the public key embedded in the credential (Mitra et al., 25 Dec 2025).

Password-based and biometric variants replace certificates with cryptographic witnesses or helper data. PDIDs store password metadata

$m \gets \langle k_s, p_s, P_s, P_u, c \rangle$

inside the Global Password Manager and use OPAQUE plus HMQV so that servers learn neither the password nor material sufficient for offline dictionary attacks (Szalachowski, 2020). BioZero uses Pedersen commitments

$C = c_{g,h}(m,r) = g^{m} h^{r}$

and a Groth16 proof that a committed biometric distance is below a threshold, while blockchain-based fuzzy-commitment authentication stores

$\delta = c \oplus x,\qquad t = H(w)$

rather than raw biometric templates (Lai et al., 2024, Alzahab et al., 2024).

Across these designs, the credential is rarely a bare identifier. It is a structured proof object that couples identity to code, attributes, policy, hardware state, or thresholded biometric similarity.

4. Handshakes, session binding, and authorization semantics

dAuth protocols generally separate two decisions: whether the peer controls a valid identity artifact, and whether that artifact is authorized for the current interaction. The most explicit example is Decent’s augmentation of mutual TLS. The handshake follows a standard client/server exchange but replaces ordinary certificate validation with checks over manufacturer reports, local-attestation evidence, AuthList equality, service-name membership, optional verifier signatures, and revocation state. The session key is then transcript-bound to attestation and policy material:

$$k_{AB} = \mathrm{HKDF}\big(g^{ab} \Vert \mathsf{att\_evidence}_A \Vert \mathsf{att\_evidence}_B \Vert \tau \big).$$

Decent’s authorization rule is likewise explicit:

$$\mathsf{Authorized}(u \to v) \iff \big(AL_u = AL_v\big)\ \wedge\ \big(h_u \in AL_v[S_u]\big)\ \wedge\ \big(h_v \in AL_u[S_v]\big)\ \wedge\ \neg\mathsf{Revoked}(h_u)\ \wedge\ \neg\mathsf{Revoked}(h_v).$$

This exact-match policy prevents transitive leakage by refusing communication whenever trust state differs across application components (Zheng et al., 2020).

DAXiot applies the same separation to MQTT 5.0. The client first proves possession of an ephemeral and static did:key through ECDH-ES and ECDH-1PU, then transmits an encrypted SD-JWT AuthorizationCredential, and finally obtains session authorization sets A_Pub and A_Sub that are enforced at PUBLISH and SUBSCRIBE time (Philipp et al., 2023). DID Link follows a related pattern in TLS: pseudo-anonymous DID-based authentication during the handshake, then post-handshake verifiable-credential presentation, with the presentation bound to the session by

$c_b = H(\mathrm{transcript\_hash}).$

The peer can then sign or otherwise bind the credential presentation to the current TLS channel (Garzon et al., 2024).

Dynamic authorization variants extend the model beyond static credentials. In the cross-domain IoT zero-trust architecture, a domain mints a one-time token containing scope, expiry, audience, intent, and a context hash, and then continuously re-evaluates risk with

$$R_t = \alpha\cdot \mathrm{Anomaly}(x_t) + \beta\cdot \mathrm{TrustDecay}(T_{\mathrm{device}}, t) + \gamma\cdot \mathrm{PolicyConflict}(x_t) + \delta\cdot \mathrm{TokenAge}(age_t) + \zeta\cdot \mathrm{GeoDeviation}(loc_t),$$

using thresholds for permit, re-authentication, and revocation (Ma et al., 7 Jan 2025). AgentDID turns runtime state itself into part of the authentication semantics by requiring both a nonce-bound verifiable presentation and two live checks: a Readiness Probe and a Context Consistency Check (Xu et al., 28 Apr 2026).

A common misconception is that decentralized authentication is only about replacing login. The cited systems treat authorization, replay protection, transcript binding, and often live state validation as integral parts of the authentication layer.

5. Security properties, privacy guarantees, and recurring controversies

Formal analysis in this literature is varied but substantial. Decent models Decent Server, Decent App, Decent Verifier, Decent Revoker, and Verified App in ProVerif, and verifies secrecy and authenticity under an attacker that can control the host OS or hypervisor, intercept messages, run malicious enclaves, and provide malicious configuration, while keeping manufacturer keys secret. The verified correspondence property states that acceptance implies a valid certificate chain, AuthList equality, and authorized code identity (Zheng et al., 2020).

AgentDID gives a theorem-style security statement: if the signature schemes used in DID and VC operations are EUF-CMA secure, the VC system is sound, the publicly detectable watermarking scheme is secure, and the context-hash function is collision resistant, then the probability that an adversary causes an honest verifier to accept either an identity forgery or a state forgery is negligible in the security parameter (Xu et al., 28 Apr 2026). BioZero offers a different profile: Pedersen commitments are statistically hiding, Groth16 contributes soundness and zero-knowledge, and Fiat–Shamir plus nonce binding provides replay resistance in decentralized biometric authentication (Lai et al., 2024).

Yet the literature is equally clear about limitations. Decent states that availability is not guaranteed; hosts can drop or shut down services, and the design may need coupling with BFT or service-mesh retries if availability is required (Zheng et al., 2020). DAXiot explicitly notes that its reuse of a single ECDH-1PU execution for the session loses forward secrecy (Philipp et al., 2023). Verifiable Passkey prevents issuer tracking at presentation time because PageX is static and client-only, but it does not provide per-RP unlinkability if the same VC and public key are reused across verifiers (Mitra et al., 25 Dec 2025). PDIDs aim for privacy comparable to present password authentication and do not provide per-service unlinkability (Szalachowski, 2020). The Web3 bridge for aggregated identities is explicitly unidirectional and “limits root trust of credentials,” while its dependence on centralized systems remains a live point of debate (Biedermann et al., 23 Jan 2025).

These tensions recur across implementations. Decentralization can strengthen integrity or reduce online mediation while still leaving open questions about availability, revocation freshness, runtime privacy, linkability, or governance. The literature therefore treats dAuth less as a solved primitive than as a family of security trade-offs.

6. Implementations, measured behavior, and deployment limits

The practical appeal of dAuth depends on whether its extra trust logic can fit modern systems. The performance results are mixed but concrete. In DecentHT, a Chord-like DHT inside SGX, reusable self-attestation certificates and TLS session tickets make short, stateless sessions fast; on the YCSB benchmark, DecentHT achieves up to 7.5× higher throughput and 3.67× lower latency than a non-Decent SGX RA-only implementation for short sessions (Zheng et al., 2020). DAXiot shows a smaller but still measurable cost profile in MQTT 5.0: connect latency is 115.8 ms for DAXiot versus 91.2 ms for mutual TLS, while publish latency is 6.3 ms versus 5.7 ms (Philipp et al., 2023).

Ledger-anchored DID systems are more sensitive to resolution latency. DID Link reports comparable TLS handshake durations when verification material is cached, but if DID documents are fetched from a ledger during the handshake, latency grows by 3.23× with a local VON ledger, 31.58× with remote BCovrin, and 12.12× with remote IDunion (Garzon et al., 2024). AgentDID reports identity authentication latency of about 6.5 s, Readiness Probe latency of roughly the same magnitude, Context Consistency Check latency under 1 s, total protocol latency around 13.5 s, and throughput from 0.07 TPS in the 1v1 setting to 3.25 TPS in the 50v50 setting (Xu et al., 28 Apr 2026).

Other designs expose different bottlenecks. PDIDs report user registration at about 7 ms, user authentication total at about 10 ms, server authentication total at about 1.63 ms, Global Password Manager authentication at about 19.00 ms, and note that end-to-end latency is dominated by blockchain consensus, which in the reported Hyperledger Fabric setting is 500–800 ms (Szalachowski, 2020). BioZero reports approximately 200× faster authentication than a “Vanilla ZKBio” design and about 2 seconds end-to-end, with constant Groth16 verification gas because the public inputs remain scalar-sized (Lai et al., 2024).

Operationally, the main deployment limits are not identical across systems. Exact-match policy equality in Decent can create friction for large deployments, so nested AuthLists and service-scoped verifiers are suggested (Zheng et al., 2020). Verifiable Passkey does not define a revocation or update mechanism and leaves recovery to re-issuance (Mitra et al., 25 Dec 2025). DID-centric systems require resolver caching, DID-method governance, and status mechanisms mature enough to avoid turning decentralized trust into remote-ledger latency (Garzon et al., 2024). Biometric systems still depend on careful entropy, revocation, and liveness design, even when the on-chain protocol hides templates (Alzahab et al., 2024, Lai et al., 2024).

Taken together, these results indicate that dAuth is already implementable across microservices, IoT, TLS, passkeys, AI agents, password systems, and biometric pipelines. This suggests a broad architectural shift rather than a single standard: authentication moves from centrally mediated identity assertions toward verifiable state, reusable proofs, and decentralized policy evaluation.