NTN · 2026-04-08
Delay-Tolerant Identity: Authentication Protocols for ~480 ms Round-Trip Latency
By J. W. Bouckaert
Authentication over long links
Most authentication protocols in use today were designed for terrestrial networks, where a round trip to the server takes tens of milliseconds. OAuth 2.0, OpenID Connect, SAML 2.0 and WebAuthn all exchange several messages with a server before the user is signed in.
Satellite links change that arithmetic. Starlink Direct to Cell, AST SpaceMobile's BlueBird satellites and the 3GPP non-terrestrial network (NTN) standards first published in Release 17 bring phones and other devices onto links where propagation delay, not server time, sets the floor.
This article works through the latency numbers, the parts of current protocols that depend on a live server, the design options for authenticating when the server is slow or unreachable, and what PasskeyBridge provides today.
Propagation delay by orbit
Light travels at about 299,792 km/s. For a "bent-pipe" satellite that relays a signal from a user terminal to a ground gateway, a full request and response crosses the user-to-satellite distance four times. The table gives the physical minimum for a satellite directly overhead; real paths are longer, and processing and queuing add more.
| Orbit | Example altitude | Ground to satellite, one way | Request and response, minimum |
|---|---|---|---|
| LEO | About 550 km (Starlink) | 1.8 ms | 7.3 ms |
| MEO | 8,062 km (O3b mPOWER) | 26.9 ms | 107.6 ms |
| GEO | 35,786 km | 119.4 ms | 477.5 ms |
| Moon (direct link) | 384,400 km | 1.28 s | 2.56 s |
A geostationary link therefore adds close to half a second to every round trip before any server work.
Measured latency is higher than these minimums because of routing, ground stations and queuing. Starlink's service plans document gives latency of 25 to 50 ms in most regions on land and says latency on the ocean can reach more than 100 ms.
Round trips in a sign-in
The delay multiplies with each round trip a protocol needs. A new HTTPS connection needs a TCP handshake and a TLS 1.3 handshake before the first request. An OAuth 2.0 authorization code flow then adds the authorization request, the redirect back, the token request and the first API call. A WebAuthn sign-in adds a request for the challenge and a request to submit the assertion. Certificate status checks through OCSP add another round trip unless the server staples the response.
Over a GEO link, five or six round trips add roughly three seconds of propagation delay alone. Sign-in still works, but it is slow, and a short-lived token can expire while a refresh is in flight.
Parts of current protocols that need a live server
Challenge and response
Challenge-response protocols prove freshness: the server sends a random challenge, and a valid response shows the client signed it after the challenge was issued. That guarantee requires contact with the server at the moment of sign-in.
Token refresh
OAuth 2.0 refresh tokens reduce how often a user runs the full flow, but each refresh is still a round trip to the authorization server.
Revocation
OCSP needs a live responder. Certificate revocation lists can be cached but must be refreshed. Stapling moves the OCSP round trip to the server, which helps only if the server itself has good connectivity.
Design options for slow or absent links
Delay-tolerant networking applies store-and-forward to data transport. NASA's Delay/Disruption Tolerant Networking program and the IETF Bundle Protocol (RFC 9171) define how data moves across links that are slow or intermittent. Authentication can borrow the same approach: do the expensive checks while the link is good, and carry a signed result that can be checked later.
A design along these lines has to decide five things:
- Proof issuance. The server issues a signed proof after a full sign-in over a good link.
- Signature algorithm. A proof that may be held for hours or days should use a signature that will still be trusted for that long. ML-DSA (FIPS 204) is a standardized post-quantum option.
- Freshness. Without a live challenge, the proof must carry its issue time and expiry, and the verifier needs a clock it trusts.
- Binding. Unless the proof is bound to a key held on the device, a copied proof can be replayed from another device.
- Revocation. The verifier needs a way to learn that a proof was revoked. Options are short lifetimes, a revocation list cached during good connectivity, or invalidating every proof issued in a time window.
For cached revocation data, the W3C Bitstring Status List (a Recommendation since May 2025) records one bit per credential. The specification uses a minimum list length of 131,072 entries, and a list in which few credentials are revoked compresses to a few hundred bytes.
Signature sizes
| Property | ES256 (P-256) | ML-DSA-65 (FIPS 204) |
|---|---|---|
| Signature size | 64 bytes | 3,309 bytes |
| Public key size | 65 bytes (uncompressed) | 1,952 bytes |
| Quantum resistant | No | Yes |
A hybrid signature that carries both adds the two sizes together. On a narrowband satellite link the extra 3.3 KB is worth counting; on a broadband link it is small.
PasskeyBridge cached proofs today
PasskeyBridge has a cached proof API for Enterprise tenants. It does not yet provide offline verification. Specifically:
- A tenant stores a proof (a trust token, a cached verifiable credential or a passkey attestation) with a trust level of standard, high or critical and a lifetime from 1 to 720 hours (72 by default).
- The user identifier is stored as a keyed HMAC-SHA-256 digest, and the proof payload is encrypted with AES-256-GCM.
- When the tenant has post-quantum signing enabled, the proof's hash is signed with a hybrid signature (ML-DSA-65 with ES256, or ML-DSA-87 with ES384, depending on the tenant's signing level).
- The tenant can record whether the device had network access when the proof was stored.
- Validation is a call to PasskeyBridge that checks whether the proof has been revoked or has expired, and can compare a payload hash. Revalidation marks a proof as checked again once the device is back online. Administrators can revoke proofs.
- Server time comes from Postgres, with a default allowed clock drift of 5 seconds and a strict setting of 500 ms, and a public time endpoint lets clients check their clock.
What it does not do: proofs are not bound to a device key, there is no on-device or local verifier, and trust does not decay with proof age. Validation needs one round trip to PasskeyBridge. Over a GEO link that is one round trip instead of a full sign-in, which saves time, but a device with no link cannot validate a proof.
Use cases that need offline verification
- Ships on GEO backhaul, where crew sign in during port calls and need access at sea.
- Aircraft, where crew sign in at the gate and use flight systems in the air.
- Field operations in places where communications are jammed or unavailable.
- Disaster response, where terrestrial networks are down.
- AI agents running on hardware with intermittent cloud access.
Each needs local verification with device binding and a cached revocation list. These features would build on the non-terrestrial trust anchors and hybrid signatures described elsewhere on this blog.