Selective SSI — not a general DIDComm wallet

Claim: identity standards in service of a vault

Decentralized Identifiers give software a public name that can resolve to verification material the holder can prove control of. That pattern is useful for a structured vault: each vault can have a stable cryptographic face for optional cloud auth, contact addressing, and signed Share packages—without making email the root of ownership.

NT² adopts that pattern selectively.

We use Vault Key DIDs (did:key) as the public identity of a vault. We use peer DIDs for vault-to-vault encryption relationships. We resolve DID Documents locally from material the product already holds. We verify signatures and encrypt to agreement keys with platform cryptography. Those pieces make identity and Share honest: the vault proves itself; recipients can check who signed; intermediaries can move sealed bytes without reading fields.

We do not ship NT² Vault as a general self-sovereign identity wallet. The vault app is not a Verifiable Credential issuer console, not a DIDComm agent that speaks every ecosystem message type, and not a blockchain-anchored identity directory. Product vocabulary may borrow Holder / Verifier / selective-disclosure ideas where they clarify Share and presentation UX. The wire formats and client libraries stay vault-native.

The claim in one line: selective SSI means adopting DID patterns that serve a zero-knowledge vault—and refusing the gravity well of a general DIDComm / VC wallet.

That claim sits beside the identity and Share essays already on this blog: Threshold Vault and Key DID, challenge–response auth, Share passphrase ≠ master password, and blind Share relay / local Inbox. This post is the standards boundary underneath them.

Constraint: SSI ecosystems pull toward generality

SSI standards are powerful because they aim at interoperability across wallets, issuers, verifiers, and mediators. That ambition creates product gravity.

If you adopt Verifiable Credential JSON-LD as storage or Share wire format, you inherit an issuer–holder–verifier world. Status lists, proof suites, presentation exchange, and “export as VC” become natural requests. A vault that stores login templates and identity documents as W3C credentials starts competing with dedicated SSI wallets—and starts carrying libraries, schemas, and threat models that do not match a local-first ciphertext store.

If you embed a DIDComm v2 client in the vault UI, you inherit routing, packing, and agent semantics. DIDComm is a messaging stack for agents. A vault Inbox that Accepts sealed packages is not an agent chat product. Pulling in a general DIDComm library invites every protocol feature the dependency exposes—even features that conflict with blindness, local staging, or “Accept is a door on the device.”

If resolution equals trust, phishing wins. Successfully parsing a DID URL into a DID Document proves key material shape. It does not prove that the human behind a contact is who they claim. Out-of-band fingerprint checks and explicit trust states exist because cryptography alone does not replace human confirmation.

If “credential” in the product means W3C VC, language collapses. NT²’s structured credential category is a login-shaped asset template (username, password, URL)—not a Verifiable Credential document. Mixing those meanings in UI or APIs trains users and integrators to expect the wrong export and the wrong threat model.

If standards compliance becomes the product goal, the vault stops being a vault. Full SSI coverage is an infinite surface: more DID methods, more proof systems, more mediators, more issuer roles. A zero-knowledge personal vault needs a finite surface: unlock locally, store structured ciphertext, share under explicit boundaries, optionally sync and relay blindly.

The constraint is therefore architectural, not aesthetic. We take standards where they reduce ambiguity for vault identity and Share. We refuse standards payloads and client stacks that pull the browser vault UI into becoming a general identity agent.

Design: three layers — identity, messaging, delivery

NT² separates standards touchpoints into three layers so each can stay honest.

flowchart TB
  subgraph identity [Identity]
    KeyDid[Vault Key DID]
    PeerDid[Peer DID per connection]
    Doc[DID Document locally]
  end
  subgraph messaging [Messaging]
    Env[NT² Share / Inbox envelopes]
    Thread[thread correlation]
  end
  subgraph delivery [Delivery]
    Relay[Blind relay]
    File[File / QR / paste]
  end
  identity --> messaging
  messaging --> delivery

Identity layer. A Vault Key DID is the public face of the vault’s signing key. Optional cloud APIs authenticate with challenge–response over that DID—not with a resettable email login. Secure contacts address other vaults by Key DID. Share packages can be signed so recipients verify origin. Peer DIDs bind encryption material to a specific vault-to-vault link so Mode A delivery encrypts to the relationship, not to a reused master secret. Resolution for the methods we support is local: the DID URL and connection material are enough; we do not depend on a global DID directory to open your vault.

Messaging layer. Inbox rows and Share packages use NT² envelopes. Stable message-type URIs and thread identifiers help integrators and future gateways correlate request, response, and acknowledgement. Those fields rhyme with DIDComm ideas—threading, ack, out-of-band invites—without importing a DIDComm client. Selective disclosure in product terms means Mode D presentation and field masks: show or attest what is needed, not dump the whole item. That is Holder / Verifier semantics without storing assets as Verifiable Credentials.

Delivery layer. Bytes may travel through a blind relay that indexes ciphertext, through a .nt2share file, or through QR / in-band paste. The Vault Inbox that stages Accept stays on the device. A mediator analogy helps explain the relay; it does not authorize shipping DIDComm packing and routing libraries into the browser vault UI.

Cryptographic profile (v1). Sign and verify use ECDSA P-256. Encrypt for vault-to-vault uses ECDH P-256 with HKDF into AES-GCM. Keys live behind local unlock. The edge verifies signatures and moves opaque blobs; it does not become an issuer of your life’s credentials.

Resolution is not trust. A contact whose DID Document parses correctly is still untrusted until the user confirms fingerprints or an explicit trust action. Blocked contacts cannot be Share recipients. Standards give you keys; people still choose relationships.

Trade-off: less universal interoperability, clearer product

Selective adoption costs some ecosystem fantasy.

Integrators who expect a drop-in DIDComm agent will not find one in the vault app. Partners who want every asset exported as JSON-LD Verifiable Credentials will need a different product—or a future, explicitly decided adapter at the boundary, not a silent dependency in the core UI. Wallet ecosystems that assume blockchain-anchored DID methods are outside v1 on purpose.

We also accept dual vocabulary. Engineers familiar with SSI will recognize roles and mediator analogies in our docs and protocols. End users meet Share, Inbox, Accept, and Contacts—not a tour of W3C acronyms. That dual language is maintenance work. It is cheaper than teaching every vault user that their password entry is somehow a Verifiable Credential.

The gain is focus. Dependency weight stays closer to Web Crypto and vault-native crypto. Threat modeling stays about unlock, envelopes, Share secrets, and blind relays—not about every VC proof suite and DIDComm routing quirk. Product copy can say “credential” for a login template without promising a global issuer. Architecture changes that would pull VC JSON-LD or DIDComm clients into the vault app require an explicit product and architecture decision—not a drive-by npm install.

Interoperability is not abandoned; it is staged. Public DID Core concepts remain the identity substrate. Message-type URIs and local resolution keep a door open for future edge adapters that translate at the boundary while the vault UI stays a vault. Until that door is opened deliberately, the app refuses to become the adapter.

What we refuse

We refuse shipping general Verifiable Credential JSON-LD (or JWT-VC) stacks as the vault’s storage or Share format. Assets stay structured vault items under per-object envelopes. Presentation is a product mode, not a VC document pipeline.

We refuse embedding DIDComm v2 client libraries in the vault app without a new, explicit architecture decision. Blind relay and Inbox envelopes are enough for v1 delivery. Agent chat stacks are not a free upgrade.

We refuse treating DID resolution as automatic trust. Fingerprints and trust states remain human gates.

We refuse conflating the asset category “credential” with a W3C Verifiable Credential. Words matter; collapsing them invites the wrong libraries.

We refuse blockchain-anchored DID methods and global DID directories as vault identity roots in v1. Local did:key / peer patterns fit a device-held vault. Anchoring is not required to unlock, sync, or Share.

We refuse NT² operating as a global Issuer of people’s credentials. When a vault signs an attestation, it is usually self-attestation under the user’s Key DID—not NT² vouching for identity documents as a network authority.

We refuse “full SSI compliance” as a substitute for vault security rules. Master passwords stay on device. Keys stay non-extractable where the product promises it. Relays stay blind. Share secrets stay share-shaped. Standards do not override those refusals.

These refusals disappoint anyone shopping for a universal identity agent. They protect anyone shopping for a zero-knowledge vault that happens to use DID patterns where they help.

Close: standards as tools, not the product

Selective SSI is how Null Trust² shows up in identity engineering: take the cryptographic proofs that keep the provider blind; leave the agent-wallet surface that would make the provider (or a dependency) central again.

The practical identity story remains Threshold Vault and Key DID. Cloud proof remains challenge–response over a Vault Key DID. Share crypto remains a share-shaped secret, not the master password. Delivery remains relay indexes ciphertext; Inbox stays local. Trust-layer stories—Contacts, Accept, timed reveal—stay product language for the same boundaries.

We adopt DID patterns that serve the vault. We refuse the general DIDComm / VC wallet. That is the standards alignment, written for engineers who have to choose dependencies under a threat model—not under a slogan.

If you want a vault that uses identity standards without becoming an identity product, explore NT² Vault.