Does self-sovereign identity work offline?

Self-sovereign identity moves the credential to the holder: the person keeps a private key and their credentials on their own device. The W3C verifiable credentials model names three roles. An issuer makes claims and signs them into a credential, a holder stores credentials and presents them, and a verifier receives and checks them.

Whether this works offline depends on which checks the verifier needs to make. A full check has five parts:

1. Holder control. The holder signs a fresh challenge with their private key.
2. Issuer signature. The credential carries the issuer’s signature over its claims.
3. Key lookup. The verifier finds the public keys for the holder and the issuer.
4. Validity period. The credential is within its start and end dates.
5. Status. The credential has not been revoked or suspended.

Steps 1, 2 and 4 are local work. Steps 3 and 5 are where a network can come in.

Checking a signature is a calculation on the verifier’s device. Once it has the right public key, no one else is involved. The W3C Decentralized Identifiers standard says DIDs were designed so they may be decoupled from centralised registries, identity providers and certificate authorities, so that the controller of a DID can prove control over it without requiring permission from any other party.

The validity period is local too. VC Data Model 2.0 defines validFrom and validUntil, and a verifier compares them with its own clock. That clock has to be right, which is worth checking on devices that have been offline for a long time.

Key lookup. A DID is resolved to a DID document, which lists its keys. The DID standard says that to be resolvable, DIDs are typically recorded on a verifiable data registry, such as a distributed ledger, a decentralised file system, a database or a peer-to-peer network, and the steps for resolving a DID are set by its DID method. So resolution may or may not work offline depending on the method, and on whether the verifier cached the document earlier. An identifier derived directly from a public key, a self-certifying identifier, avoids the lookup: presenting the key is enough to check it matches.

Status. VC Data Model 2.0 defines credentialStatus for finding out whether a credential is suspended or revoked, and gives fetching an externally linked revocation list as an example of a status check. The Bitstring Status List specification publishes that status as a compressed list of bits and notes that verifiers can cache status lists they have fetched. A cached list works offline, but only tells the verifier what was true when it was fetched. Anything revoked since then will still pass, which is why revocation for offline devices has to be planned separately.

A working example of holder-held credentials checked offline is the mobile driving licence standard, ISO/IEC 18013-5. Google’s developer guide for accepting IDs from Google Wallet describes in-person presentation with no active internet connection needed at the time of presentation:

• The reader and wallet make first contact by an NFC tap or a QR code scan, exchanging the reader’s ephemeral public key.
• They then set up an encrypted Bluetooth Low Energy channel for the data.
• The reader asks for specific data elements, and the holder confirms sharing with biometrics or the screen lock.
• The wallet returns signed data, and the reader verifies the signatures against trusted root certificates.

Apple’s ID Verifier lets an iPhone read ISO 18013-5 compliant mobile IDs in person with no extra hardware. In the flow Google describes, the reader can verify with no connection because it already holds the trusted root certificates, which is the same preparation any offline verifier needs.

• Trusted issuer keys or roots, so it knows whose signatures count.
• Cached identifier documents for any identifiers that need resolution.
• A recent status list, with a rule for how old it may be before the verifier stops accepting credentials it covers.
• A correct clock, for validity periods.
• Fresh challenges, so a recorded presentation cannot be replayed. VC Data Model 2.0 uses an event ticket presented by several people as its replay example and lists a verifier-supplied challenge, enforced as unique, as a defence.

With those in place, self-sovereign identity does work offline for the checks that matter most in person. What it cannot do offline is learn something new.