Authentication, with and without a server
NIST’s digital identity guidelines define authentication as determining the validity of one or more authenticators used to claim a digital identity, by establishing that the subject is in control of the secrets used to authenticate. The party that does the checking is the verifier. In everyday online sign-in the verifier is a server: the app sends a password, a one-time code or a signed response, and the server looks up the account and answers.
Offline authentication keeps the checking but moves it. The verifier is the device in front of you, such as a phone at a gate, a tablet in a vehicle, or a peer in a mesh, and it has to decide with only what it already holds. That is possible when authentication rests on public-key signatures, because checking a signature needs only the signer’s public key, not a call to anyone.
Three things a verifier can check with no connection
A key it already knows. If two devices exchanged public keys earlier, by pairing, scanning a QR code, or being enrolled by an administrator, each can later check the other’s signatures directly. Ed25519, specified in RFC 8032, is one digital signature scheme used for this. Accepting a key the first time it is seen and pinning it afterwards is called trust on first use.
A credential signed by an issuer it trusts. When the verifier has never met the holder, a trusted third party can vouch in advance. The issuer signs a set of claims about the holder, and the verifier checks that signature with the issuer’s public key, which it cached earlier. A JSON Web Token (RFC 7519) is one format for this: its claims can be carried in a signed structure, and its expiration time claim marks when it must stop being accepted. The W3C Verifiable Credentials Data Model describes the same pattern as three roles, issuers, holders and verifiers, with validity periods and an optional status entry for revoked or suspended credentials.
Proof that the holder is present now. A signed credential can be copied. To show that the device presenting it also holds the matching private key, the verifier sends a fresh random challenge and checks the signed reply. NIST calls the property this gives replay resistance: recording an old authentication message and playing it back should not succeed. Challenge-response authentication explains the exchange.
Combined, these let one device decide on another with no network at all: the key is bound to a credential the verifier trusts, and the challenge shows the key is present.
What still needs a server
Offline checks depend on work done online beforehand, and some questions cannot be answered from cached data.
- Enrolment and issuance. Someone has to verify the person and sign the credential, or record the device’s key, while a connection exists.
- Current status. A verifier only knows about revocations it has downloaded. The Verifiable Credentials specification also requires status schemes not to let an issuer learn when a verifier checks a particular holder, ruling out “phoning home” on every use. Whatever status scheme is used, an offline verifier sees only the status it last received.
- Ordinary web sign-in. The WebAuthn specification behind passkeys requires the relying party to generate challenges randomly in an environment it trusts, such as its server, and to check that the response matches. The PIN or biometric gesture happens on the device; the sign-in to a website is still checked by that website.
What offline authentication does not tell you
A valid signature proves that someone holds a key. It does not prove what that person is allowed to do, whether their account is still active, or that the credential has not been withdrawn since it was cached. Three habits follow:
- Keep authorisation separate. Decide what each verified identity may do in the application, with rules that are themselves available offline.
- Use expiry, and mind the clock. RFC 7519 allows a small leeway for clock skew when checking expiry, but a device with a badly wrong clock can accept expired credentials or reject valid ones.
- Plan for revocation lag. Choose credential lifetimes and refresh intervals that match how long a stale decision would be tolerable.
Offline Protocol’s OfflineID shows these limits in a concrete form. Its React Native package can fetch an issuer-signed credential that binds an account, a username and a device’s off1 address, signed with Ed25519 and carrying issue and expiry times. The documentation says a cached credential permits offline signature verification but does not establish current account status or replace application authorisation, and the hosted sign-in that obtains it needs the network.