Challenge–response, not bearer email

Claim: the vault proves itself with a signature

When NT² Vault uses optional cloud features, the edge must answer a simple authorization question: does this requester control the cryptographic identity registered for this vault?

The answer is not “does this person still control a particular email inbox?” It is not “does this browser still hold a long-lived bearer token that once meant login?” It is a challenge–response exchange over a Vault Key DID—a public identifier bound to the vault’s signing key.

The device signs a short-lived server challenge. The server verifies the signature against public material it already associates with that vault. A valid signature authorizes a limited cloud session for transport work: registering the account, moving encrypted replicas, attaching opaque blobs, and similar blind operations. It does not open the vault. It does not reveal the master password. It does not make ciphertext readable.

That claim is narrower than “log in to the cloud,” and deliberately so. Local unlock and cloud authentication are different events with different secrets. This essay is about the second event: how the vault proves continuity to a service without turning email into ownership.

Constraint: email and bearer tokens accumulate the wrong power

Most consumer accounts begin with an email address. The address locates the record. A password or magic link proves control of the inbox. Password resets, support escalations, and device switches all orbit that same mailbox. The model is familiar because the provider already stores the authoritative data. Whoever can reclaim the inbox can usually reclaim the account, and reclaiming the account restores access to the data.

An encrypted, local-first vault reverses the dependency. The useful copy lives on the user’s devices. Sensitive contents are ciphertext at rest. Opening them requires local cryptographic material. The optional cloud is a blind relay and entitlement layer, not the place where secrets become readable. If email remains the root of cloud identity, several dangerous equivalences appear:

• Inbox takeover becomes vault-account takeover. A compromised mail provider, a recycled address, a successful phishing reset, or a support override can reassign “who this account is” without ever touching the vault’s signing key.
• Password reset language creeps into vault recovery. People expect “forgot password” to mean the provider can restore access. For server-owned data, that expectation is often true. For a zero-knowledge vault, it would require the provider to hold or reconstruct unlock power it should not have.
• A long-lived bearer session becomes a substitute for proof of presence. Tokens that survive lock, refresh, and tab close start to look like ownership rather than a short authorization for transport. Stolen session material then grants cloud rights without a fresh cryptographic demonstration.
• Display names and billing contacts are mistaken for authority. A label on the device picker and an address for receipts are useful. Neither should authorize sync, registration, or share-relay operations.

Email remains useful at the edges. NT² may store an optional billing email for merchant-of-record receipts. That field is a communication address, not a cryptographic root. Treating it as identity would quietly restore the account model the product is designed to avoid.

Bearer-email systems also blur the unlock boundary. If cloud “login” is the same mental event as opening the vault, product flows start asking the server whether the master password is correct, or they start treating a cloud session as proof that local ciphertext may be shown. Both moves pull the provider into the unlock path. We keep those paths separate for the same reason we keep password-checkable material out of the account database: helpful centralization becomes an oracle when the wrong questions become answerable.

The constraint, then, is negative as well as positive. Cloud authentication must prove control of the vault’s signing identity now. It must not invent a second root of ownership in an inbox, a support desk, or a durable cookie that outlives the unlocked session.

Design: challenge, sign, verify, then a short session

A Vault Key DID is the public face of the vault’s signing key pair. In the language of Decentralized Identifiers, it is an identifier that resolves to verification material the holder can prove control of. NT² uses that pattern for vault-shaped cloud identity, not as a general-purpose identity wallet. The private signing key stays on the client. After local unlock, the device may unwrap it into memory for the unlocked session. The server never receives it.

Cloud registration and protected APIs therefore follow a small protocol:

1. The client asks the edge for a challenge bound to its Vault Key DID.
2. The edge returns a fresh, short-lived nonce.
3. The device signs that nonce locally with the vault’s private signing key, using the platform Web Cryptography API.
4. The edge verifies the signature against the registered public key.
5. On success, the edge issues an opaque session token for authorized cloud calls.
6. Later requests carry the session token together with the Vault Key DID header so the service knows which identity the session belongs to.

sequenceDiagram
  participant Device as Unlocked device
  participant Edge as NT² edge
  Device->>Edge: Request challenge for Vault Key DID
  Edge-->>Device: Fresh short-lived nonce
  Device->>Device: Sign nonce with private signing key
  Device->>Edge: Return DID + signature
  Edge->>Edge: Verify against registered public key
  Edge-->>Device: Limited cloud session token
  Device->>Edge: Authenticated transport calls (ciphertext only)

The freshness of the challenge matters. An old captured response must not authorize a new session. The binding to a specific Vault Key DID matters. A signature for one vault must not authorize another. The limited lifetime of the session matters. Cloud rights should expire, and vault lock, vault switch, vault delete, or leaving the page should clear the token so a locked browser does not keep a usable cloud credential.

Registration is identity binding, not escrow. The edge stores the Vault Key DID and the public verification material needed to check future signatures. It can record whether the account is disabled and whether Premium entitlements allow sync. It does not receive the master password, the local KDF salt, the password verifier, or unwrapped private keys. Those belong beside the local vault copy.

What the resulting session can do is also bounded. It can authorize movement of opaque replica batches and attachment ciphertext. It can let the service recognize the same vault across devices that already share unlock material through user-controlled handoff. It cannot decrypt items, derive the vault AES key, or answer whether a guessed master password is correct. Authentication grants transport rights. Unlock grants plaintext. Confusing the two is how zero-knowledge marketing collapses into ordinary account software.

The local display name never becomes the cloud primary key. People need a human label on the device; the edge needs a stable cryptographic identifier. Separating those concerns keeps picker UI readable without teaching the server a recoverable human identifier as the root of authority.

Trade-off: two proofs, fewer familiar recoveries

Challenge–response identity is honest, and honesty has costs.

Users and operators must reason about two proofs. Local unlock answers whether this device can derive or reconstruct the vault key. Cloud authentication answers whether this unlocked vault can sign as the registered identity. Those states vary independently. A vault can be unlocked offline with no cloud session. A cloud session can expire while the vault remains unlocked. Sync can fail because the session needs renewal even though local search still works. The product has to explain “cloud needs attention” without implying that the vault is locked, and “vault locked” without implying that encrypted replicas on the edge have disappeared.

Familiar recovery stories become unavailable by design. NT² cannot send a magic link that reassigns vault ownership to whoever controls an inbox. Support cannot inspect billing history and mint a new signing identity that still opens the old ciphertext. An email change must remain a receipt-routing change, not an identity migration. Continuity depends on user-held paths: portable backups, approved recovery factors, and explicit device handoff. That is more work for the person who owns the secrets. It is also the only recovery model that does not secretly appoint the provider as locksmith.

Implementers inherit edge cases. Session clearing must be synchronous with lock and unload so a refresh cannot leave a usable token behind. Challenge reuse must be rejected. Public key rotation, if ever introduced, must not be confused with password reset. Tests must cover combinations of locked/unlocked and authenticated/expired rather than a single happy-path “logged in” flag.

We accept the complexity because it keeps powers from accumulating in one credential. A mail compromise should threaten messages and maybe billing communication—not redefine who may push or pull this vault’s ciphertext. A stolen cloud session should be time-bounded transport abuse—not proof that someone knows the master password. A server breach should expose public identifiers and encrypted blobs—not a password-testing kit or an inbox-based ownership override.

What we refuse

We refuse to make email vault identity. An optional billing email may receive receipts. It does not locate the cryptographic account, authorize sync, or reset control of the vault.

We refuse bearer-email “login” as a substitute for proof of key control. Possession of an inbox is not possession of the signing key. Magic links and inbox resets are the wrong authority for an encrypted vault’s cloud surface.

We refuse to treat a cloud session as a decrypted vault. A verified signature authorizes blind transport. It does not imply that the master password was entered on this device or that any item is readable.

We refuse long-lived cloud credentials that outlive lock. When the vault locks or the page goes away, the session token must go with it. Cloud calls after unlock must be able to demand a fresh challenge–response instead of silently reusing yesterday’s proof.

We refuse to upload private signing keys or master-password material to “make auth easier.” The edge verifies public signatures. It does not become a custodian of the means of proof.

We refuse support tooling that reintroduces inbox-rooted ownership. A private admin flow that reassigns a vault because someone proved email control is still an identity override. Restricting who can press the button is weaker than not creating the button.

These refusals close some conventional product promises. They keep the cloud useful without letting it appoint itself the owner of the vault.

Close: prove the seal, keep the inbox at the edge

Challenge–response over a Vault Key DID is a small protocol with a large boundary. The vault stamps a one-time card. The edge recognizes the seal. The inbox, if present at all, stays where receipts belong.

That design sits beside the rest of NT²’s trust story. Local unlock is not cloud login—see Unlocking a local vault is not logging in to the cloud. Blind sync moves ciphertext without reading it—see Blind replica sync on the edge. The account database must not become a password oracle—see The account database must not become a password oracle. The broader identity model is sketched in Threshold Vault and Key DID, and the naming promise behind the refusals is what Null Trust² means.

If you want optional cloud features that recognize a vault by signature instead of by inbox, explore NT² Vault.