Self-sovereign identity
Self-sovereign identity is an approach to digital identity in which the credential belongs to the holder rather than to an issuer or provider. The identity is a cryptographic keypair generated and stored on the user’s own device, so proving who you are is a signature and verifying you is a local computation. Because no central authority has to be online to vouch for you, self-sovereign identity works anywhere two devices can exchange data.
How it works
Conventional digital identity is a lookup. A server, a certificate authority, or an identity provider vouches for you, and verifying you means asking it. With no connectivity there is no verification, and the credential lasts only as long as the issuer keeps answering.
Self-sovereign identity moves the credential to the holder. The identity is a keypair: a private key kept on the device and a public key others can check against. Proving identity means signing a challenge with the private key, and verifying it means checking the signature with the public key, a purely local computation with no server in the loop.
The hard parts are lifecycle: how keys rotate, how a lost or stolen device is revoked, and how trust is established on first contact. Practical systems answer all three without reintroducing a permanent central dependency, often using self-certifying addresses, expiring credentials, and session re-keying rather than a global revocation list.
Why it matters
Self-sovereign identity keeps authentication working when infrastructure is down or unreachable: in a blackout, underground, or in the field. It also reduces reliance on a single provider that could fail, change terms, or become a bottleneck.
Because private keys stay on the device, the holder controls their credential, and verification does not require exposing personal data to a third party.
How it relates to Offline Protocol
Offline Protocol implements self-sovereign identity as OfflineID. Each identity is an Ed25519 keypair generated on the device, and the private key never leaves it. Verifying a peer is a local signature check over BLE or QR, with the address derived from the key, so devices and people authenticate each other with zero connectivity. A hosted directory binds the key to an account and issues an expiring credential; there is no on-chain record.
These identities also anchor the encrypted sessions the mesh uses via MLS (RFC 9420). See offline identity for the full lifecycle, including rotation and revocation.
Frequently asked questions
How does self-sovereign identity work without a server?
The identity is a keypair on the holder’s device. Proving identity is a signature made with the private key, and verifying it is a local check with the public key, so no server or certificate authority needs to be online.
What happens if a device holding a self-sovereign identity is lost?
Sessions with that key are re-keyed, its credential expires on its fixed lifetime, and the replacement device binds a fresh key to the account, so every verifier that refreshes the credential sees the new key.
How is first contact trusted without a certificate authority?
By deriving the address from the key: presenting the key proves the address, so there is nothing to pin. An out-of-band confirmation such as a QR scan confirms first contact.
