Sigma Auth's hosted offering is cloud backup as a service for self sovereign identity: your keys stay yours, and what Sigma stores is an encrypted blob it cannot read, findable again through an account you already have.
The model in one paragraph
You (or a tool acting for you) generate a Bitcoin keypair and a BAP identity. Your keys are encrypted on your device with a password that never leaves it. Sigma stores the resulting ciphertext and records one mapping: the sub claim of an OAuth account you connect (Google, GitHub) points at your BAP identity. Later, on any device, signing in with that OAuth account locates the encrypted blob, and your password decrypts it locally. At no point does a private key or a backup password reach the server.
Social is a recovery handle, not a second identity
The OAuth account plays exactly one role: it is the handle that finds your backup.
- Your identity is the BAP key. Applications, signatures, and on-chain attestations all bind to it. Nothing binds to the Google or GitHub account.
- The social login proves nothing about identity. It only proves you can still open the mailbox or account you connected, which is what makes it a workable recovery factor.
- Losing the social account does not destroy the identity. The keys are the identity; connect a different recovery handle and the same BAP identity carries on. Conversely, someone who compromises the OAuth account still cannot decrypt the backup without the password.
If you have seen systems where "sign in with Google" creates the identity, this is deliberately not that. The OAuth restore guide walks through the recovery flow step by step.
Where the identity comes from
Sigma does not have to be the thing that mints your identity. Any tool that produces a BAP identity works with the backup service — for example, ClawNet mints BAP identities from its CLI. The division of labor is:
- Minting — a CLI or wallet generates the keys and the BAP identity. This happens entirely outside Sigma's servers.
- Backup — the keys are encrypted client-side (see the bitcoin-backup package) and the ciphertext is stored with Sigma.
- Mapping — Sigma records
OAuth sub → BAP identityso the backup can be located during recovery. - Recovery — OAuth sign-in locates the blob, your password decrypts it locally, and the restored keys sign you in.
What the server holds, exhaustively
| Data | Held by Sigma | Readable by Sigma |
|---|---|---|
| Encrypted backup blob | Yes | No — ciphertext only |
OAuth sub → BAP mapping | Yes | Yes — it is the lookup key |
| Backup password | No | No — never transmitted |
| Private keys | No | No — encrypted before upload |
This is a structural guarantee rather than a policy one: the decryption secret never transits the server, so there is nothing to leak, disclose, or be compelled to hand over. The security page documents the encryption parameters.
Practical guidance
- Use a strong backup password and store it in a password manager. It is the one secret that decrypts everything, and it cannot be reset.
- Connect more than one OAuth provider if you can. Recovery handles are cheap redundancy.
- Keep an offline copy of the encrypted backup if you want zero dependence on the hosted service; the blob is portable and decrypts with the same package anywhere.