NTN · 2026-04-08

Delay-Tolerant Identity: Authentication Protocols for 600ms+ Round-Trip Latency

By J. W. Bouckaert

The latency wall

Every authentication protocol in production today was designed for a world where the server is 20 milliseconds away. OAuth 2.0, WebAuthn, FIDO2, OpenID Connect, SAML 2.0—all of them assume that a challenge can be issued, a response can be computed, and a token can be returned within a window that a human perceives as instantaneous.

That assumption is about to break.

As non-terrestrial networks (NTN) move from experimental to operational—Starlink's Direct-to-Cell service, AST SpaceMobile's BlueBird production constellation (following the BlueWalker 3 prototype), the 3GPP NTN standards in Release 17—identity verification must function over links where the speed of light is the bottleneck, not the server.

When your authentication server is 36,000 km away, the laws of physics impose a 600ms floor on every round-trip. No amount of engineering can optimize away the speed of light.

Identity verification will need to work over high-latency links. What decides the design is whether today's protocols can be adapted—or whether we need a fundamentally different architecture.

The physics of orbital latency

Round-trip latency over satellite links is governed by orbital altitude and the speed of light (299,792 km/s). The propagation delay is deterministic and irreducible—no CDN, no edge cache, no protocol optimization can reduce it below the physical minimum.

These are propagation delays only. They do not include processing time, queuing delay, or the additional round-trips that authentication protocols require. A standard OAuth 2.0 authorization code flow requires three round-trips. Over GEO, that is 1.8 seconds of pure propagation delay—before a single byte of authentication logic executes.

The protocol multiplier

Authentication protocols multiply the base latency by the number of round-trips required to complete the ceremony:

At GEO latency, a user attempting to authenticate through a standard OAuth flow with TLS negotiation and certificate revocation checking faces a three-second minimum before the application receives a valid token. That is an unusable experience.

Failures of existing approaches

Challenge-response

The fundamental design pattern of modern authentication—challenge-response—is inherently latency-sensitive. The server issues a cryptographic challenge, the client computes a response, and the server validates the response. This three-step pattern requires at least one full round-trip, and most protocols require two or three.

Challenge-response exists to prove freshness: the server's challenge is a nonce that prevents replay attacks. Without a fresh challenge, an attacker could capture a valid authentication response and replay it indefinitely.

The problem is that freshness and latency are adversarial. Proving that an authentication event happened now requires communication with the server now. Over GEO links, "now" is a 600ms window.

Token refresh breaks at scale

OAuth 2.0 refresh tokens partially address the problem by reducing the frequency of full authentication ceremonies. But refresh token exchanges still require a round-trip to the authorization server, and the security model depends on short-lived access tokens (typically 5–15 minutes). Over high-latency links, a token can expire during the refresh attempt itself—creating a race condition between token validity and propagation delay.

Certificate revocation is latency-hostile

Both OCSP (Online Certificate Status Protocol) and CRL (Certificate Revocation Lists) distribution require server communication. OCSP requires a real-time round-trip to the responder. CRLs can be cached but grow large and require periodic refresh. Over GEO links, OCSP adds 600ms to every TLS handshake, and CRL refresh windows may exceed the interval between authentication attempts.

OCSP stapling mitigates the client-side round-trip by having the server include a signed OCSP response in the TLS handshake, but this assumes the server has recent connectivity to the OCSP responder—an assumption that fails when the server itself is behind a high-latency link.

The delay-tolerant identity architecture

The solution is architectural. Delay-tolerant identity inverts the authentication model: instead of proving identity through real-time server communication, the device pre-positions cryptographic proofs during favorable connectivity windows and presents them locally when network conditions degrade.

This is the same store-and-forward principle that NASA's Delay/Disruption Tolerant Networking (DTN) architecture applies to data transport—but extended to the identity layer with cryptographic freshness guarantees.

Architectural principles

1. Pre-positioned Proofs: Identity assertions are generated and signed during low-latency windows (terrestrial connectivity or favorable LEO passes) and cached on the device
2. PQC-Signed Timestamps: Each proof carries an ML-DSA-65 (FIPS 204) signed timestamp that binds the assertion to a specific moment, preventing timestamp manipulation even by quantum-capable adversaries
3. Configurable Freshness Tolerance: Verifiers accept proofs within orbit-appropriate time windows—seconds for LEO, minutes for GEO, hours for cislunar operations
4. Device Binding: Proofs are cryptographically bound to the device's hardware identity, preventing proof exfiltration and relay attacks
5. Graceful Degradation: Trust level decreases as proof age increases, enabling graduated access control rather than binary authentication failure

The cached proof lifecycle

┌─────────────────────────────────────────────────────────────┐
│                  LOW-LATENCY WINDOW                         │
│  (Terrestrial / Favorable LEO Pass / Ground Station Link)   │
│                                                             │
│  1. Device authenticates via standard ceremony              │
│  2. Server issues Cached Proof Bundle:                      │
│     ├── Identity assertion (user_hash + tenant_id)          │
│     ├── ML-DSA-65 signed timestamp                          │
│     ├── Device fingerprint binding (hardware hash)          │
│     ├── Trust level at issuance (e.g., "verified")          │
│     ├── TTL + maximum freshness tolerance                   │
│     └── PQC signature over entire bundle                    │
│  3. Device stores proof in secure enclave / TEE             │
└─────────────────────────────────────────────────────────────┘
                          │
                          │  Connectivity degrades
                          │  (LEO → MEO → GEO → disconnected)
                          ▼
┌─────────────────────────────────────────────────────────────┐
│                HIGH-LATENCY WINDOW                          │
│  (GEO Backhaul / Intermittent LEO / Store-and-Forward)      │
│                                                             │
│  4. Device presents cached proof to local verifier          │
│  5. Verifier checks:                                        │
│     ├── PQC signature validity (ML-DSA-65)                  │
│     ├── Timestamp freshness (within orbit tolerance)         │
│     ├── Device binding (hardware hash match)                 │
│     ├── Trust level ≥ required threshold                     │
│     └── Proof not in revocation set (local CRL cache)       │
│  6. Access granted at degraded trust level                  │
│  7. Verification event queued for async audit logging       │
└─────────────────────────────────────────────────────────────┘
                          │
                          │  Connectivity restored
                          ▼
┌─────────────────────────────────────────────────────────────┐
│                 REVALIDATION WINDOW                         │
│                                                             │
│  8. Device initiates full re-authentication                 │
│  9. Server revalidates cached proof history                 │
│  10. Queued audit events flushed to immutable log           │
│  11. Fresh proof bundle issued (cycle repeats)              │
└─────────────────────────────────────────────────────────────┘

PQC-signed timestamps: The freshness primitive

The critical innovation in delay-tolerant identity is the PQC-signed timestamp. In challenge-response protocols, freshness is proven by the server's nonce—a value that the client could not have predicted before the challenge was issued. In delay-tolerant protocols, there is no real-time challenge. Freshness must be proven by the proof itself.

The timestamp serves as a self-contained freshness assertion: "This identity proof was generated at time T, and the signature over T was computed using a key that only the issuing server possesses."

PQC signatures on long-lived proofs

Classical signatures (Ed25519, ECDSA P-256) are sufficient for today's threat model. They are not sufficient for proofs that may persist on a device for hours or days before verification—particularly in government and defense contexts where the operational lifetime of a credential may intersect with the timeline for cryptographically relevant quantum computers (CRQCs).

ML-DSA-65 (FIPS 204) provides NIST Security Level 3—equivalent to AES-192—with signature sizes of approximately 3.3 KB. For delay-tolerant scenarios where proofs may be cached for extended periods, the marginal bandwidth cost of a PQC signature is negligible compared to the security guarantee.

PasskeyBridge uses a hybrid signature scheme that includes both ES256 (ECDSA P-256) and ML-DSA-65, ensuring that cached proofs are verifiable by both classical and PQC-aware verifiers.

Freshness tolerance: An orbit-aware trust model

Not all latency is equal. A proof that is 5 seconds old over a LEO link is operationally equivalent to a proof that is 30 seconds old over a GEO link—both represent "recently verified" within their respective propagation environments. The freshness tolerance must be orbit-aware.

Tolerance tiers

The trust decay function follows the same exponential decay model used in PasskeyBridge's agent trust system:

Trust(t) = T₀ × e^(-t/τ)

Where:
  T₀  = Trust level at proof issuance (0.0–1.0)
  t   = Time elapsed since issuance (seconds)
  τ   = Decay constant (environment-dependent)
  
Example (GEO, τ = 1800s):
  t = 0s    → Trust = 1.00  (full trust)
  t = 300s  → Trust = 0.85  (5 minutes—read access)
  t = 900s  → Trust = 0.61  (15 minutes—degraded)
  t = 1800s → Trust = 0.37  (30 minutes—re-auth required)
  t = 3600s → Trust = 0.14  (1 hour—proof expired)

This graduated model replaces the binary authenticated/unauthenticated decision with a continuous trust surface. A device operating over a GEO link with a 10-minute-old proof can access read-only resources but cannot execute write operations—the proof's trust level has decayed below the write threshold but remains above the read threshold.

Revocation in a delay-tolerant world

Revocation is the hardest problem in delay-tolerant identity. If a credential is compromised, how do you revoke a cached proof that is sitting on a device with no real-time server connectivity?

Revocation without server contact

Standard revocation mechanisms (OCSP, CRL) require server communication—the exact capability that delay-tolerant identity is designed to work without. The paradox: the proof must be verifiable without server contact, but revocable with server contact.

Three mitigation strategies

1. Short TTLs with Aggressive Decay

The simplest approach: issue proofs with TTLs short enough that revocation becomes less critical. A proof that expires in 30 minutes has a maximum exposure window of 30 minutes if compromised. The trade-off is more frequent re-authentication during low-latency windows.

2. Local Revocation Lists (LRL)

A compact, pre-distributed revocation list that the device and local verifiers cache during connectivity windows. LRLs use the same StatusList2021 bitstring compression used in W3C Verifiable Credentials, achieving sub-kilobyte representation for thousands of revoked proofs. The device checks incoming proofs against its local LRL before accepting them.

3. Epoch-Based Revocation

Proofs are issued within numbered epochs (e.g., 15-minute windows). When a revocation occurs, the server invalidates the entire epoch. Devices that learn of the epoch invalidation—through any communication channel, including broadcast, mesh, or side-band—reject all proofs from that epoch. This provides coarse-grained but reliable revocation without per-proof communication.

Implementation: PasskeyBridge Cached Proofs

PasskeyBridge's Cached Proofs infrastructure already implements the core primitives for delay-tolerant identity:

Proof issuance

When a device authenticates over a low-latency link, the server generates a cached proof bundle containing:

• Identity assertion: user_hash + tenant_id (zero-PII—no plaintext identifiers)
• PQC signature: ML-DSA-65 over the entire proof payload
• Timestamp: Server-authoritative time from the Atomic Clock module, NTP-disciplined via Postgres clock_timestamp()
• Device binding: Hardware fingerprint hash preventing proof portability
• Trust level: verified, attested, or degraded based on the authentication ceremony
• TTL: Environment-appropriate expiration (configurable per tenant)
• Network state: Whether the device had network connectivity at issuance time

Proof verification

Verification is a local operation that does not require server connectivity:

Verify(proof):
  1. Check PQC signature (ML-DSA-65) → reject if invalid
  2. Check timestamp:
     a. Parse proof.timestamp
     b. Compare against local clock (NTP-synced if available)
     c. Apply orbit-appropriate freshness tolerance
     d. Reject if drift exceeds tolerance
  3. Check device binding → reject if hardware hash mismatch
  4. Check trust level ≥ required threshold for requested operation
  5. Check proof_hash against Local Revocation List (if available)
  6. Compute decayed trust: Trust(t) = proof.trust_level × e^(-Δt/τ)
  7. Return { valid: true, effective_trust: Trust(t) }

Async audit trail

Every cached proof verification generates an audit event that is queued locally and flushed to the immutable audit log when connectivity is restored. The audit event includes the proof hash, verification timestamp, device identifier hash, and the trust level at verification time—maintaining the SOC 2 Type II audit trail even during disconnected operations.

Operational scenarios

Maritime: Container ship authentication

A container vessel transiting the Pacific relies on GEO satellite backhaul (Inmarsat Fleet Xpress, ~650ms RTT) for crew identity verification. Standard WebAuthn ceremonies require 1.2 seconds per authentication. With delay-tolerant identity:

• Crew authenticate via passkey during port calls (terrestrial connectivity)
• Cached proofs issued with 4-hour TTL and GEO-appropriate decay (τ = 1800s)
• At-sea authentication completes in < 5ms (local proof verification)
• Proofs revalidated during twice-daily Inmarsat connectivity windows
• Audit events flushed to shore-side SOC during revalidation

Aviation: In-flight crew systems

Commercial aircraft at cruise altitude operate over Inmarsat SwiftBroadband or Starlink Aviation (LEO, ~40ms RTT). Flight deck systems require crew identity verification for Electronic Flight Bag (EFB) access:

• Pilots authenticate at the gate (terrestrial)
• Cached proofs issued with 12-hour TTL (exceeds maximum duty period)
• In-flight verification is local—no dependency on air-to-ground link
• Trust level degrades gracefully over the flight duration
• Full re-authentication occurs at destination gate

Defense: Disconnected forward operations

Military units operating in communications-denied environments (GPS-denied, satellite-jammed) require identity verification for classified system access:

• Operators authenticate at base (terrestrial, full ceremony)
• Cached proofs issued with mission-appropriate TTL and aggressive decay
• Field verification is fully offline—no network dependency
• Epoch-based revocation distributed via mesh radio or side-band
• Full audit trail reconstructed upon return to secure network

The DTN-identity convergence

NASA's Delay/Disruption Tolerant Networking (DTN) architecture and the IETF Bundle Protocol (RFC 9171) solve the transport problem for disrupted networks. Delay-tolerant identity solves the authentication problem for the same environments.

The convergence is inevitable. As NTN links become operational for commercial, maritime, aviation, and defense applications, the identity layer must adopt the same store-and-forward principles that the network layer already uses. The difference is that identity proofs require cryptographic freshness guarantees that network-layer bundles do not—which is why PQC-signed timestamps and trust decay functions are essential primitives.

Identity is the last protocol layer still assuming the server is always reachable. The rest of the stack has already adapted. It is time for authentication to catch up.

Beyond satellite operators

Delay-tolerant identity is the foundation for authentication in any environment where connectivity is intermittent, degraded, or governed by the speed of light, and satellite operators are only the most visible case:

• Non-terrestrial networks: LEO, MEO, GEO, and cislunar operations
• Maritime and aviation: Where GEO backhaul is the primary connectivity path
• Underground and submarine: Where connectivity is physically impossible for extended periods
• Disaster response: Where terrestrial infrastructure is destroyed or degraded
• Autonomous agent operations: Where AI agents operate in environments with intermittent cloud connectivity

The protocols exist. The cryptographic primitives are standardized. The infrastructure for cached proofs is operational. What remains is adoption—and the recognition that the terrestrial assumptions baked into every authentication protocol in production today are already obsolete for a growing fraction of identity verification scenarios.

The speed of light is a design constraint. Build for it.

Start free · Test the API