Verify identities offline with OfflineID
Know exactly who you are talking to before you trust a message or answer an invocation. This guide covers how OfflineID authenticates peers device-to-device with zero connectivity, and what happens when a device is lost.
An authentication flow where two devices verify each other with Ed25519 device-owned identity, derive addresses from keys, and bind them to accounts through a hosted directory, verifying offline, with no server and no certificate authority in the loop.
Why offline identity
Conventional digital identity is a lookup: a server, a certificate authority, or an identity provider vouches for you, and verifying you means asking it. No connectivity, no verification. Device-owned identity moves the credential to the holder. The identity is a cryptographic keypair generated and stored on the device, so proving identity is a signature and verifying one is a local computation.
OfflineID is that credential in production. The hard parts are the lifecycle ones: how a key is tied to an account, what happens when a device is lost, and how first contact is trusted. This guide covers each and is explicit about where a hosted directory is involved. See offline identity, explained for the deeper treatment.
Prerequisites
- The SDK installed and initialized, which creates the OfflineID on the device.
- Two physical devices that can exchange bytes over BLE, or a QR code shown on one and scanned on the other.
- A decision on how you want first contact confirmed: address-from-key alone, or an out-of-band invite or QR exchange for a confirmed binding.
Steps
Each identity is an Ed25519 keypair generated on the device when you initialize the protocol. The private key never leaves the device, not for backup and not for sync, so there is nothing central to compromise.
When two devices meet, over BLE or a QR exchange, each proves control of its key with a signature the other checks locally. No server, CA, or identity provider is contacted, which is why it works in a basement, a blackout, or anywhere two devices can exchange bytes.
A peer address is a hash of its Ed25519 key, so a device proves its address by presenting the key. Nothing is pinned and nothing is looked up; a mismatch raises a security warning. An invite or QR exchange confirms first contact out of band when you need it.
A device key is bound to an account through a signed challenge, credentials carry a fixed lifetime, sessions re-key on demand, and a reinstalled device rebinds a fresh key. There is no on-chain record and no gossip-carried revocation list; call rekeySession for the affected peer and let the credential expire.
The calls to read your identity, verify a peer, and handle rotation are in the API reference. Follow the documentation for the exact signatures.
What you get
A trust layer that works anywhere two devices can exchange bytes: peers you can name and verify, keys that never leave the device, and a lifecycle of expiring credentials and session re-keying. Pair it with messaging to attribute every message, and with service discovery to decide per identity who may invoke a capability.
Next steps
Offline identity FAQ
How do you verify identity without an internet connection?
The credential is an Ed25519 keypair on the device itself, so verification is a local signature check between two devices over BLE or a QR exchange. No server, CA, or identity provider is contacted, which is why it works with zero connectivity.
How is first contact trusted without a CA?
The address is derived from the key, so presenting the key proves the address with nothing to pin. An invite or QR exchange confirms first contact out of band.
What happens if a device is lost or stolen?
Sessions with that peer are re-keyed, its issued credential expires on schedule, and the account rebinds a fresh key from the replacement device through the hosted directory, so the account moves to the new key. Verifiers that work offline pick up the change the next time they refresh the credential.
Can organizations issue identities to a fleet?
Yes. Each unit mints its own Ed25519 identity on first start. Your backend binds each unit's address to your fleet records by having the unit sign a server nonce and checking that its key derives the address, and OfflineID can bind an account to that address with an issuer-signed credential. Rotation is a rebind, and verification in the field stays fully offline.
