Offline identity verification with self-sovereign identity
Offline identity is a self-sovereign credential two parties verify device-to-device with zero connectivity, with no server or certificate authority in the loop. OfflineID does it in production with Ed25519 keys and 300,000+ identities issued.
What is self-sovereign 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. The credential is also only as durable as the issuer's willingness to keep answering.
Self-sovereign identity moves the credential to the holder. The identity is a cryptographic keypair generated and stored on the user's device. Proving identity is a signature, and verifying one is a local computation: no server in the loop, which means it works anywhere two devices can exchange bytes.
The hard problems are lifecycle ones: how keys rotate, how a stolen device is revoked, and how trust is established on first contact. A production system has to answer all three without reintroducing a central dependency.
Diagram: offline identity verification between two devices, a self-sovereign Ed25519 key fingerprint handshake that checks a signature locally and returns verified offline with zero connectivity, no server, and no certificate authority.
The whole handshake is local: scout-12 sends a challenge, amara's device signs it with a key that never left the hardware, and the signature verifies in under a second. No certificate authority, no identity provider, no network. The check badge is the only output that matters: verified, offline.
How OfflineID implements it
Each identity is an Ed25519 keypair generated on the device. Private keys never leave it, not for backup, not for sync.
Verification is a local signature check over any transport, including QR and BLE, with trust-on-first-use pairing. Works in a basement, a blackout, or a jammed environment.
Key rotations and revocations anchor on-chain. Any node that touches the internet picks up the update and carries it back into the mesh.
Identities sign data at capture, producing tamper-evident, attributable field records for coordination and collection workflows.
300,000+ OfflineIDs issued, in production across 80+ countries.
Offline authentication compared to OAuth and identity providers
Teams evaluating offline authentication usually start from what they know: OAuth flows, SSO, or certificate chains. All of them verify by asking a third party a question over the network, which makes the network a dependency of every login. Cache a token and you have deferred the problem, not solved it; the token still expires, and issuing a new one still needs the server.
OfflineID removes the question entirely. Because the credential is the keypair and verification is local math, two field devices authenticate each other in under a second with no round-trip, and the same identity then secures service invocations and MLS-encrypted sessions across the mesh.
Identity is the middle layer of the platform, and it is exposed through the same React Native and TypeScript SDK surface as transport and coordination, so adding offline verification to an existing app is an SDK integration, not a new identity stack.
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.
- Rotation and revocation
- When a key rotates or a device is reported stolen, the record anchors on-chain once and spreads by gossip: any node that touches the internet carries the update back into disconnected pockets, so peers stop accepting a revoked key without their own connectivity.
- 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.
- Agent invocation
- 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.
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, not a mesh of separate pairwise threads. So identity extends to encrypted groups, still device to device, with no server holding the roster or the keys.
Groups run on MLS (RFC 9420), the same protocol that secures one-to-one sessions. Any member can create a group, invite peers, and send messages that only the current members can read: meshCreateGroup, meshInviteToGroup, meshSendGroupMessage, meshRemoveFromGroup, and meshLeaveGroup manage the lifecycle over the mesh.
Authority is explicit. Each group has two roles, admin and member, and the creator is automatically admin. Only admins can invite, remove, or change roles. The last admin cannot be demoted, removed, or leave, so a group is never orphaned, and if the last admin disconnects, a deterministic election promotes the next admin. Use meshSetMemberRole, meshGetMemberRole, and meshGetGroupRoles to manage access, and the group_role_changed event reports every change.
// Create a group; you become admin automatically
const group = await protocol.meshCreateGroup('Project Team');
// Invite a member (admin only)
await protocol.meshInviteToGroup(group.groupId, 'bob');
// Send an encrypted group message
await protocol.meshSendGroupMessage(group.groupId, 'Hello team!');
// Promote a member to admin (admin only)
await protocol.meshSetMemberRole(group.groupId, 'bob', 'admin');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?
The identity is revoked on-chain. The revocation propagates through internet-connected nodes into the mesh, and peers stop accepting the key.
How is first contact trusted without a CA?
Trust-on-first-use: the first verified exchange pins the peer's key, and any later change is flagged. Out-of-band confirmation, such as a QR scan, upgrades the binding.
Does on-chain anchoring mean identity data is public?
No. Only rotation and revocation records anchor on-chain. Personal data and 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.
Can OfflineID be used in web apps?
Yes. The ID SDK brings OfflineID identities and connections to React and React Native apps on the connected side, so a web dashboard can recognize 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 the Identity Service: OTP-based login backed by JWTs, so a web backend verifies the same holder the mesh verified offline, and every request it receives is attributable to that identity.
