Threshold Vault and Key DID: identity without handing over the keys

The account model most of us live with

Most online accounts start with an email address. The email becomes your username, your recovery path, your support handle, and sometimes the thing a service quietly treats as "you."

That is convenient, but it also means identity is usually anchored outside the product you are using. If you lose access, the service can often reset you through email, SMS, a support workflow, or an administrator. That is useful for a streaming account. It is much more uncomfortable for a vault that holds identity documents, seed phrases, bank details, and credentials.

NT² takes a different path. Your vault has its own cryptographic identity, and the keys behind that identity are protected by a threshold vault. Those phrases can sound heavy, so here is the plain version:

• Your vault has a stable public name it can prove, called a Vault Key DID.
• The private keys that make that proof possible stay encrypted inside your vault.
• Unlocking the vault is not based on one secret sitting in one place.
• NT² servers can verify that your vault is speaking, but cannot become your vault.

That is the practical core of self-sovereign identity in NT²: not a slogan, not a blockchain account, and not a promise that software can replace passports. It means the app is designed so you hold the power to unlock, prove, share, and recover.

What a threshold vault means

A normal password-protected vault often feels like a single lock: type the master password, derive a key, open the data.

NT² adds another layer. When a new vault is created, the important vault root material is split into shares. Think of it like a safe that needs two pieces of evidence, not just one key. In the current model, the useful pieces are:

Two of the three can reconstruct what the vault needs to unlock. One alone is not enough.

That design changes the recovery story. NT² does not keep a server-side copy of your recovery share. There is no hidden support key. If you are on your trusted device, your password plus the device share can unlock. If you move to a cold device, your password plus your recovery kit can help restore access. If you choose biometric unlock on a device, it is a local convenience over the same threshold model, not a cloud bypass.

The important user promise is not "recovery is magic." It is more honest than that:

Recovery belongs to the user, not to NT².

If you save the recovery kit carefully, you have a path that does not depend on a support desk. If you lose every required factor, NT² cannot open the vault for you. That is the same zero-knowledge line we described in Null Trust², applied to recovery instead of just encryption.

What a Vault Key DID means

Now the identity part.

A Vault Key DID is a public identifier for one vault. It looks technical because it is built on DID standards, but the job is simple: it lets your vault sign something so another system can verify, "yes, this came from that vault."

It is not your email. It is not a phone number. It is not a username chosen by NT².

When your vault talks to NT² cloud services, such as optional encrypted sync or relay, the server can send a challenge. Your unlocked vault signs that challenge with its private key. The server verifies the signature against the public Vault Key DID material. That proves control of the vault identity without asking for your master password and without reading your vault contents.

In everyday terms:

• Email says, "messages for this person arrive here."
• A password says, "someone typed the shared secret."
• A Vault Key DID says, "the vault holding this private key approved this action."

That last sentence is the difference. The cloud account identity is bound to the vault's key, not to an inbox that can receive a reset link.

Why this matters for autonomous identity

"Self-sovereign identity" can quickly become a pile of acronyms: DID, VC, DIDComm, wallets, issuers, verifiers. NT² intentionally does not try to become all of that in v1.

Instead, we take the part that matters for a structured privacy vault:

1. You can prove the vault's identity. A Vault Key DID lets a vault sign actions and packages.
2. You can choose what leaves the device. Store, Share, and Present flows are built around selected fields or selected items, not dumping the whole vault.
3. You can recover without asking us to become you. The threshold vault gives you a user-held recovery path.
4. The server stays blind. Optional cloud services move ciphertext and verify signatures; they do not receive master passwords or plaintext assets.

That is enough to make identity feel less like an account owned by a provider and more like a capability owned by the user.

Imagine a future share from one NT² vault to another. The sender's vault can sign the package. The recipient can verify which vault sent it. The payload can be encrypted for the receiving side. A relay, if used, moves sealed bytes between them. It does not need to read the bank field, API key, document scan, or note.

That is not the same as saying "trust no one." You still decide whether to trust a contact. You still need to verify the person behind a vault. But the software can give you a stronger base: proof of which vault signed the package, and encryption that keeps middlemen out.

What this does not mean

There are limits, and they matter.

NT² is not a general-purpose SSI wallet. We are not adding Verifiable Credential JSON-LD, DIDComm routing libraries, blockchain anchoring, or a global identity directory to the vault app. We borrow useful ideas from the identity world, but we keep the product focused: a local-first, zero-knowledge vault for high-value personal data.

It also does not mean a Vault Key DID is private in every context. If you share it with a contact, use cloud sync, or ask support to look up a prefix, that identifier is part of that interaction. The privacy goal is narrower and more realistic: different vaults are not automatically linked into one global profile, and NT² does not use email as the vault's identity.

Finally, threshold recovery is only as good as your factor hygiene. Saving a .nt2recovery file next to your master password on the same laptop weakens the point. Keeping it on offline media or another storage location you control makes the model meaningful.

The user experience we are aiming for

The ideal version should feel ordinary:

• You open the vault and use a master password, or a local biometric shortcut on a trusted device.
• You save a recovery kit somewhere separate, the way you would keep a spare house key somewhere sensible.
• You enable cloud sync only if you want it, knowing sync is attached to the vault's key identity and carries ciphertext.
• You share or present only the fields a moment needs.
• You do not create a cloud account with an email just to have a local vault.

The machinery underneath is deliberately serious because the data is serious. But the user-facing idea is not complicated:

Your vault should be able to prove itself without giving NT² the power to impersonate it.

That is why threshold vault and Vault Key DID belong together. One protects the root of access. The other gives the vault a stable way to be recognized. Together, they make identity something closer to an object you hold and manage, not a row in a provider's account table.

Trust should not start at the sign-up screen. It should start with understanding where the keys live, who can recover them, and what the server can never see.

You can read the broader product story at nt2.me/about, browse practical scenarios at nt2.me/help/use-cases, or follow new posts via RSS.