Self-Sovereign Tunneling: Using DIDs to Replace Centralized Auth Tokens

Stop trusting third-party providers with your auth tokens. Here’s how Self-Sovereign Identity (SSI) and Decentralized Identifiers (DIDs) are enabling a new generation of peer-to-peer tunnels — where your identity wallet is the only “login” you’ll ever need.

Introduction: The Shift Away from Centralized Tunneling

For most of the early 2020s, the developer’s toolkit for local-to-public exposure was dominated by a handful of centralized “tunnel-as-a-service” providers. ngrok, Cloudflare Tunnel, and their contemporaries became household names in developer circles. Convenient, yes. But architecturally flawed in one critical way: the provider became the gatekeeper of your identity.

To open a tunnel, you needed an account. To authenticate, you needed a Bearer Token living in a .yml file. If that provider’s database was breached — or if you accidentally committed your config to a public repo — your local environment’s entry point was wide open.

The industry is now moving through a fundamental correction. Developers are no longer renting identities from providers; they are bringing their own. This is the era of SSI-Tunnels — cryptographic handshakes between sovereign entities, built on Decentralized Identifiers (DIDs) and peer-to-peer networking, with no middleman required.

What Is Self-Sovereign Identity?

Before diving into tunnels specifically, it helps to understand the broader foundation being built beneath them.

Self-Sovereign Identity (SSI) is an identity management model that gives individuals and systems full ownership and control of their digital identities without relying on a central authority. As the W3C DID Working Group has established through its Decentralized Identifiers (DIDs) v1.0 specification, a DID is a new type of globally unique identifier that enables verifiable, decentralized digital identity — one that the owner, not a corporation or government registry, controls.

The SSI architecture rests on three participants:

Holder — the entity (person, server, or device) that creates and controls a DID via a digital wallet and receives Verifiable Credentials.
Issuer — the authority that issues cryptographically signed Verifiable Credentials about the holder.
Verifier — the party that checks the credential without ever needing to contact the issuer directly.

This “trust triangle” underpins everything from digital diplomas and healthcare records to, increasingly, authentication flows in developer tooling.

The SSI market reflects this momentum. According to recent projections, the global SSI market is expected to expand from approximately $3.49 billion in 2025 to an extraordinary $1.15 trillion by 2034, representing a compound annual growth rate of over 90%. Whether or not that forecast proves precise, the directional signal is unmistakable: decentralized identity is becoming infrastructure.

What Is an SSI-Tunnel?

An SSI-Tunnel is a secure, encrypted network bridge established between two endpoints — typically a developer’s local machine and a remote client — where authentication is handled exclusively through SSI protocols.

Unlike traditional tunnels that rely on a central relay server to validate an API key, an SSI-tunnel uses a Decentralized Identifier (DID) to prove ownership of an endpoint. There is no account to create, no token to store, and no provider database that can be breached.

Core Components

DIDs (Decentralized Identifiers) A W3C standard for a new class of identifiers that enable verifiable, self-sovereign digital identity. Each DID resolves to a DID Document containing the public keys needed for verification.

The Identity Wallet A CLI or application that holds your private keys and signs authentication challenges. Think of it as your hardware security key, but for the open internet.

KERI (Key Event Receipt Infrastructure) Proposed by Samuel M. Smith and documented in arXiv:1907.02143, KERI provides a ledger-less protocol for managing key rotations and establishing a “Root of Trust” without requiring a blockchain for every authentication event. KERI introduces Autonomic Identifiers (AIDs) — self-certifying identifiers bound to cryptographic key pairs at inception, with an append-only, hash-chained Key Event Log (KEL) that any peer can independently verify.

libp2p (P2P Transport) The underlying networking stack originally developed for IPFS and now widely adopted across the decentralized ecosystem. It handles NAT traversal (“hole punching”) to connect two machines behind firewalls directly, without routing traffic through a relay server.

The Death of the Auth Token

For years, the ngrok-auth-token was a well-known honeypot. A misconfigured CI/CD pipeline, an accidentally committed .env file, or a breach of the provider’s own database — and your local dev environment became an open door to your internal network.

In an SSI-Tunnel, there is no persistent auth token. The connection follows a Zero-Trust workflow:

Request — A client attempts to connect to your tunnel address.
Challenge — The tunnel software issues a cryptographic challenge (a nonce).
Signature — You “log in” by signing that challenge with your Identity Wallet’s private key.
Verification — The client verifies the signature against your public DID Document, resolvable via a DHT or a blockchain such as Polygon or Cheqd.

No password. No provider database. No central point of failure.

The Technical Stack in Depth

Establishing a tunnel without a centralized provider requires solving two foundational problems: identity and connectivity.

The Identity Layer: DIDs and KERI

The industry has been migrating away from “ledger-heavy” identity systems for networking tasks. Early SSI relied on writing every key change to a blockchain — expensive, slow, and operationally fragile. KERI offers a more practical alternative.

With KERI, when you start a tunnel, your CLI generates a Key Event Log (KEL). This log is a hash-chained sequence of events — Inception, Rotation, Interaction — anchored to no external ledger. Because the log is end-verifiable, any peer can confirm your identity by replaying the log. No Identity Provider (IdP) required. No network call to a blockchain node required.

Real-world SSI infrastructure is maturing around this model. Projects like Hyperledger Indy (under the Linux Foundation), the Sovrin Foundation, and the European Blockchain Services Infrastructure (EBSI) are actively deploying verifiable credential systems at scale — providing the proven substrate that SSI-Tunnels can build on.

The Connectivity Layer: libp2p and Hole Punching

Without a central relay, how do two computers behind different firewalls and NAT layers find each other?

SSI-Tunnels use decentralized peer discovery built on Kademlia-based Distributed Hash Tables (DHTs). Your tunnel announces its DID to the DHT. When a client wants to connect, it looks up the DID, retrieves the latest “multiaddress” (a structured combination of IP, port, and protocol), and initiates a STUN/TURN-style handshake to pierce the NAT — establishing a direct connection without any traffic routing through a third-party server.

Comparing Approaches

Feature	Centralized Tunnel (Legacy)	SSI-Tunnel
Authentication	Bearer Token / OAuth	DID Signature / Wallet
Trust Model	Trust the Provider	Trust the Cryptography
Data Path	Through Relay Server	Peer-to-Peer (Direct)
Logging	Provider-side (Opaque)	Forensic KERI Logs (Verifiable)
Failure Point	Provider Database Breach	None (no central store)
Cost	Monthly Subscription	Infrastructure-Free / Open Source

Why Regulatory Pressure Is Driving This Transition

Several converging forces — not just security preferences — are making DID-authenticated tunnels increasingly necessary, particularly in regulated industries.

eIDAS 2.0 and the European Digital Identity Wallet

The EU’s revised eIDAS regulation (Regulation EU 2024⁄1183), which entered into force on 20 May 2024, mandates that every EU Member State make at least one EU Digital Identity Wallet (EUDI Wallet) available to citizens and residents by December 2026. This wallet must support Verifiable Credentials, selective disclosure of attributes, and cryptographically verifiable audit trails.

For developers building in FinTech, MedTech, or any regulated EU-facing context, this is not aspirational — it is a legal deadline. Organizations in financial services, healthcare, telecommunications, and digital infrastructure must be able to accept wallet-based authentication and produce compliant audit trails. Third-party relay tunnels, which route unencrypted or opaquely logged traffic through a provider’s servers, are fundamentally incompatible with these requirements.

The Commission also adopted technical standards for cross-border wallet interoperability in November 2024, giving developers a concrete specification target to build toward.

HIPAA and Data Chain of Custody

In the United States, updated HIPAA guidance increasingly focuses on the concept of “data chain of custody” — the ability to demonstrate, with cryptographic certainty, exactly who accessed what data, when, and over what channel. A third-party tunnel provider that logs connections opaquely cannot provide this. A KERI-based SSI-Tunnel, where every connection event is signed into an immutable Key Event Log, can.

Post-Quantum Security: A Real and Present Concern

Traditional auth tokens — and the RSA or ECDSA signatures underlying most modern TLS — are vulnerable to a class of attacks known as “harvest now, decrypt later,” where an adversary stores encrypted traffic today, planning to decrypt it once a cryptographically relevant quantum computer exists.

This is no longer a theoretical future risk. NIST finalized its first three Post-Quantum Cryptography (PQC) standards in August 2024:

FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber) — for key encapsulation and encryption.
FIPS 204 (ML-DSA, derived from CRYSTALS-Dilithium) — the primary standard for quantum-resistant digital signatures.
FIPS 205 (SLH-DSA, derived from SPHINCS+) — a hash-based backup signature scheme.

A fourth standard, FIPS 206 (FN-DSA, derived from FALCON), is progressing through the standardization pipeline and is particularly relevant to SSI-Tunnels: FALCON produces compact signatures suitable for high-throughput authentication — precisely the workload that tunnel handshakes represent.

In March 2025, NIST also selected HQC as a fifth algorithm, providing an additional code-based KEM as a backup to ML-KEM.

Modern SSI-Tunnel implementations can embed PQC signatures (ML-DSA or FN-DSA) directly within the DID Document, ensuring that authentication handshakes remain secure against both classical and quantum adversaries. This is a property that no Bearer Token-based system can offer.

The Forensic Edge: Audit-Ready Networking

One of the most operationally significant features of SSI-Tunnels is their inherent auditability.

In a provider-based tunnel model, you trust that the provider’s logs are accurate — but you cannot independently verify them. The provider controls the log. In an SSI model, the Key Event Log (KEL) is the record. It is append-only, hash-chained, and independently verifiable by any party with the log and the DID’s inception key.

For a FinTech developer debugging a production database issue via a tunnel session, this means you can demonstrate to a compliance auditor — with cryptographic proof — that only a specific, authorized DID accessed the system during that session. The log is not a report generated after the fact; it is a structural property of the protocol.

This maps directly to the “Electronic Attestation of Attributes” category newly defined under eIDAS 2.0, where trust services must provide cryptographically verifiable records of interactions.

A Conceptual Workflow

While specific production tooling continues to mature, the workflow for an SSI-Tunnel differs fundamentally from the account-based model:

Step 1: Initialize your DID

Instead of ngrok config add-authtoken <token>, you generate a locally-controlled identity:

# Generate a new KERI-based Autonomic Identifier (AID)
ssi-tunnel identity create --name "local-dev-node"
# Output: did:keri:Emkr4SGBXRoRPiWXW3GR7Q...

Step 2: Establish the Tunnel

You define which local port to expose and bind it to your DID:

# Start a P2P tunnel bound to your DID identity
ssi-tunnel share http://localhost:3000 --id did:keri:Emkr4SGBXRoRPiWXW3GR7Q...
# Tunnel active at: did:keri:Emkr4SGBXRoRPiWXW3GR7Q.tunnel

Step 3: Peer Authentication

When a collaborator or client wants to connect, their environment does not just “hit the URL.” Their client performs a DIDAuth handshake:

The client sends a DIDAuth Request containing a cryptographic challenge (nonce).
Your local machine sends a push notification to your Identity Wallet.
You approve the connection.
The signed response is verified against your public DID Document.
The P2P stream is established — directly, without routing through any relay.

The entire exchange is logged to the KEL on both sides.

Real-World SSI Infrastructure: What Already Exists

The SSI-Tunnel concept is not built on hypotheticals. It inherits from a body of production infrastructure that is already deployed:

Hyperledger Indy / Aries (Linux Foundation) — a blockchain implementation specifically designed for decentralized identity, with an agent framework for credential exchange. Used by governments and enterprises globally.
Sovrin Network — an open-source SSI infrastructure using a permissioned ledger for Verifiable Credentials.
EBSI (European Blockchain Services Infrastructure) — a pan-European initiative supporting digital diplomas, cross-border identity, and government services, directly underpinning eIDAS 2.0 compliance.
ID Union (Germany) — a decentralized identity network involving banks, universities, and government bodies.
Finland’s MyData — a citizen-controlled personal data framework operating in production across public and private services.

These aren’t proofs-of-concept. They are the infrastructure layer that DID-authenticated developer tooling can build on today.

Limitations and Honest Caveats

A credible assessment requires acknowledging where SSI-Tunnels are still maturing:

Usability gap. Managing cryptographic keys, DID Documents, and identity wallets remains technically demanding. The shift places responsibility for key security on the developer or user — lose your private key, and recovery is non-trivial. Traditional passwords are bad; lost keys are worse.

Interoperability fragmentation. Multiple DID methods exist (did:web, did:key, did:keri, did:ion, etc.), and they do not all interoperate cleanly. The lack of a universal protocol creates ecosystem friction.

Tooling immaturity. Production-grade SSI-Tunnel tooling is still emerging. Developers willing to adopt this pattern today are early adopters building on libraries and protocols, not polished products.

Scalability of KERI-based systems. While KERI avoids blockchain overhead for individual connections, high-frequency witness infrastructure still requires careful operational design.

Digital equity. SSI systems assume reliable internet access, compatible devices, and sufficient digital literacy. This is worth naming as a genuine limitation even in a developer-focused context.

What Comes Next

The trajectory is clear even if the timeline is uncertain:

Browser-native DID support. Proposals exist in the W3C for browsers to natively handle DIDAuth handshakes, removing the need for separate CLI clients on the end-user side. eIDAS 2.0’s mandate for EUDI Wallet integration into large online platforms by end of 2027 will accelerate this.

Autonomous microservice identity. Servers will use DIDs to negotiate connections with each other for microservice communication, moving toward a genuinely “provider-less” infrastructure layer.

Decentralized service discovery. Human-readable names mapped to DIDs via decentralized name services (ENS, .did namespaces) will replace the random-string subdomain model that current tunnel providers depend on.

PQC-native DID Documents. As ML-DSA and FN-DSA adoption accelerates following NIST’s 2024 finalization, expect DID implementations to ship post-quantum key types as defaults rather than options.

Conclusion

The transition to SSI-Tunnels is more than a security upgrade — it is a structural correction to a decade-long architectural mistake. Centralized providers inserted themselves as identity gatekeepers not because the technology required it, but because the tooling to do otherwise didn’t exist yet. That tooling now exists, or is rapidly being built.

The W3C DID standard is finalized. KERI is specified and under active development. NIST’s post-quantum cryptographic standards are published. eIDAS 2.0 is law. The regulated industries that represent the highest-value developer use cases are converging on exactly the properties — verifiable audit trails, sovereign identity, no central point of failure — that SSI-Tunnels provide by design.

Your auth token was always a liability. Your identity wallet is a cryptographic proof. The difference matters.

Further reading: W3C DID Core Specification · KERI Protocol Paper (arXiv:1907.02143) · NIST PQC Standards · eIDAS 2.0 Regulation (EU 2024⁄1183) · Hyperledger Indy · Sovrin Foundation

Search This Blog

InstaTunnel