Verify identities offline with OfflineID
Last updated
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 how rotation and revocation work.
An authentication flow where two devices verify each other with Ed25519 self-sovereign identity, pin keys on first contact, and honor on-chain revocation, all 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. Self-sovereign 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 keys rotate, how a stolen device is revoked, and how trust is established on first contact. This guide covers each without reintroducing a central dependency. 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: trust-on-first-use, or an out-of-band QR scan for a stronger 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.
Trust-on-first-use pins the peer key on the first verified exchange, and any later change is flagged. An out-of-band confirmation, such as a QR scan, upgrades the binding to a stronger one when you need it.
Key rotations and revocations anchor on-chain. If a device is lost or stolen, its identity is revoked, and the revocation propagates through any internet-connected node back into the mesh, so peers stop accepting the key.
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 revocation path that propagates whenever any node touches the internet. 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?
Trust-on-first-use: the first verified exchange pins the peer key, and any later change is flagged. An out-of-band confirmation, such as a QR scan, upgrades the binding to a stronger one.
What happens if a device is lost or stolen?
The identity is revoked on-chain. The revocation propagates through internet-connected nodes into the mesh, and peers stop accepting the key. Only rotation and revocation records anchor on-chain; private keys stay on the device.
Can organizations issue identities to a fleet?
Yes. Fleet operators provision OfflineIDs per unit and manage rotation and revocation centrally while verification stays fully offline.
