Offline identity verification
Each device holds its own key and proves it with a signature, so two devices can check who they are talking to with no server, no certificate authority, and no signal. OfflineID, our identity layer, runs this in production with 330,000+ identities issued.
Diagram: offline identity verification between two devices, a device-owned Ed25519 key fingerprint handshake that checks a signature locally and returns verified offline with zero connectivity, no server, and no certificate authority.
With no network in range, scout-12 verifies amara's identity from a single signature.
What is device-owned identity?
Identity is a lookup. Today, proving who you are means asking someone else: a server, a certificate authority, an identity provider. Out of range, nobody can be verified. And when the issuer stops answering, every identity it issued stops working.
The key stays on the device. An OfflineID is an Ed25519 keypair made on the device itself. The private half never leaves it, not for backup, not for sync. The device proves who it is by signing, not by asking.
Checking it is just math. The other device verifies the signature on its own. That is the whole trick: two devices anywhere, over Bluetooth, a QR code, or a mesh hop, confirm each other with no one else in the loop.
One key, no authority to ask
OfflineID is the identity layer we built for Offline Protocol. Each device gets an address it can prove on its own, and the hard questions have answers: which account owns this key, what happens when a device is lost, and how first contact is trusted.
The credential
Every identity is an Ed25519 keypair made on the device. The private key never leaves it.
One signature check, run locally, over Bluetooth, a QR code, or the mesh. The address is derived from the key, so there is nothing to look up.
A signed challenge ties the device key to an account. An issuer-signed credential carries that binding, so a peer can check it offline.
Readings, reports, and photos are signed as they are captured, so every field record says who made it and cannot be altered quietly.
How a peer is verified
- PresentThe peer sends its public key and its address. The address is a hash of the key, so there is nothing to look up and nothing to pin.
- ChallengeThe verifier sends fresh random bytes. Only the holder of the private key can produce a valid signature over them.
- Sign and checkThe peer signs the challenge. The verifier checks the signature against the public key, on its own, with no round-trip.
- CredentialWhen an account matters, the peer presents an issuer-signed credential over address, account, and username, checked with an issuer key the verifier already holds.
Illustration: a verification trace on scout-12 checking amara k. on unit-07. The public key and address are presented, the address is recomputed from the key and matches, a 32-byte challenge is signed and the signature verifies, and an issuer-signed credential over address, account, and username checks out. Result: verified offline, zero network calls.
Hover a step to see it in the trace.Present: the address is recomputed from the key, so a forged address fails before any challenge.Challenge: fresh bytes every time, so a recorded signature cannot be replayed.Sign and check: one Ed25519 verification, computed on scout-12 alone.Credential: the issuer key is held locally, so the binding checks without the directory.
Compared to OAuth and identity providers
Once two devices trust each other, everything else rides on it: service calls, encrypted sessions, signed records. Identity sits between transport and coordination in the platform and ships in the same React Native and TypeScript SDK, so adding it to an app is a few calls, not a second identity stack.
Group messaging and roles
Coordination in the field is rarely one to one. A patrol, a response team, or a fleet of agents needs a shared channel, so identity extends to encrypted groups, still device to device, with no server holding the roster or the keys.
Illustration: a group roster for Project Team with four members. amara k. is the admin and creator, bob was just promoted to admin, diego r. and gate-01 are members. A group_role_changed event notes the promotion.
// Create a group; you become admin automatically
const group = await protocol.meshCreateGroup('Project Team');
// Invite and message, encrypted with MLS
await protocol.meshInviteToGroup(group.groupId, 'bob');
await protocol.meshSendGroupMessage(group.groupId, 'Hello team!');
// Roles: admin or member (admin only)
await protocol.meshSetMemberRole(group.groupId, 'bob', 'admin');
protocol.on('group_role_changed', (event) => render(event));Under the hood
The lifecycle beneath the handshake, each point verified against the SDK.
The lifecycle, without a central dependency
- Trust on first use
- The first verified exchange pins the peer's public key, and any later key change is flagged loudly instead of silently accepted. An in-person QR scan upgrades "same key as last time" to "verified holder", the trust model that secured SSH for three decades.
- Lifecycle
- 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; sessions and credential lifetimes bound the blast radius of a lost device.
- Fleet scale
- An operator provisions an OfflineID per vehicle, handset, or badge, manages rotation and revocation centrally, and gets field verification that works with zero connectivity, while a dispatch dashboard and a drone in a jammed valley still agree on who is who.
- Portable across apps
- A user's profile and connection graph are portable across apps built on the protocol, so a new app starts with an existing network, and the same credential that verified face to face authenticates against connected services when a link exists.
Where it applies
- Field formations
- Vehicles joining a formation in the field, authenticated device to device.
- Constrained devices
- Agents invoking each other's capabilities across the mesh.
- Humanitarian operations
- Staff and beneficiaries verified without connectivity.
- Every invocation
- Every service discovery call runs inside an OfflineID-authenticated session.
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 in a basement, a blackout, or a jammed environment.
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.
How is first contact trusted without a CA?
The address is a hash of the key. A peer proves its address by presenting the key it derives from, so there is nothing to pin and nothing to look up; a mismatch raises a security warning. An invite or QR exchange confirms first contact out of band.
What does the hosted directory hold?
The binding between an account and its device address, proven by a signed challenge, plus an issuer-signed credential with a fixed lifetime. Private keys never leave the device.
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.
Can OfflineID be used in web apps?
Yes. @offline-protocol/id-react (0.2.0) and @offline-protocol/id-react-native (0.3.3) bring OfflineID sign-in, profiles, and connections to React and React Native apps, so a web dashboard recognizes the same identities the mesh uses in the field.
What does verification look like for a person, not a device?
The same signature check, surfaced through the app: scan a QR code or come within BLE range, and the other party’s identity verifies locally in under a second, with no account lookup.
How do connected services authenticate OfflineID holders?
Through OfflineID sign-in: an email one-time code opens a session backed by a signed JWT that your backend verifies against the published signing keys, so a web service verifies the same holder the mesh verified offline, and every request it receives is attributable to that identity.
How is OfflineID priced?
By monthly active users: 1,000 a month on Free, 10,000 on Pro, and 50,000 on Scale, then $0.02 per additional monthly active user. Verification between devices is a local signature check and is never metered.
Is OfflineID sign-in free, and what happens at the free limit?
The Free plan includes 1,000 monthly active users a month with no card required. Pro includes 10,000 and Scale 50,000, and with a card on file each additional monthly active user is $0.02. On Free without a card, reaching any monthly quota pauses all of the organization's metered hosted services, OfflineID sign-ins included, until you add a card or choose a paid plan, or the next billing period starts. Verifying identities between devices is a local check and is never metered. See pricing.
