Skip to content
Hussh
Connect MCP

Signature Vault — user-owned signature pattern in One

North-star user-owned signature pattern. Treat Secure Enclave and signing workflow details as future-state unless checked route, storage, test, and deploy proof exists.

Concept

TL;DR: Signature Vault is the north-star user-owned signature pattern in One: a signature should be consent-gated, short-lived at use time, auditable, and impossible for a partner system to treat as reusable signing material. Specific Secure Enclave, storage, and signing-flow details remain future-state unless checked route, storage, test, and deploy proof exists.

Status as of 2026-05-19: North-star pattern; not a shipped e-signature service.

Relations

  • One — the platform Signature Vault is a feature of.
  • Kai — participates only when the signing workflow is finance, brokerage, or portfolio related.
  • Nav — consent and scope-review direction for signing semantics.
  • PCHP — the consent receipt + ephemeral envelope primitives Signature Vault uses.
  • iBrokerage — a v1 surface that will use Signature Vault for KYC and brokerage account opening.
  • Signature Vault Flow Sequence — Flow sequence diagram

Why this exists

Every consequential digital interaction needs a signature: contracts, KYC documents, prescriptions, sponsored research agreements, fund subscription docs, identity-proof attestations, partner MOUs. Today the user navigates a fragmented landscape — DocuSign for contracts, Apple Pay biometrics for purchases, ID.me for federal KYC, manual photographed signatures for academic deliverables, and a long tail of one-off scribbles into web forms.

The Signature Vault is the consent-first replacement for that fragmentation: one user-owned signing pattern, invoked through One, checked by consent semantics, and recorded for audit. It is a One pattern, not a separate product.

The four primitives

1. Stored signature

The user's handwritten signature is stored in the Private Vault as an image (PNG with transparent background, typical 267×107px) encrypted under AES-256-GCM with the key bound to the Secure Enclave biometric (Face ID / Touch ID) on the user's device. The plaintext signature never leaves the device. Storage cost: tens of kilobytes. Sync across the user's devices uses the same end-to-end encrypted channel as the rest of the vault.

Whenever a document or workflow needs the signature, Kai presents the request and Nav enforces consent semantics:

  • What: the exact document or workflow asking for signature, with full preview.
  • Why: the asserted purpose (KYC, contract, research deliverable, etc.).
  • Scope: one-time, multi-use, or time-bound.
  • Audit hook: the entry that will land in the Transparency Log.

The user's biometric unlocks the vault for one signing operation. The plaintext signature is materialized in a short-lived ephemeral envelope (per PCHP), used, and discarded. Re-use requires re-consent.

3. Cryptographic attestation

Every signed document carries an attestation block:

  • SHA-256 hash of the final document.
  • Unique nonce generated at sign time (cryptographically random, single-use).
  • UTC timestamp of the sign event.
  • Signing platform identifier (e.g., an AI-mediated workflow label, or "Hussh One — Signature Vault v1" for native One workflows).
  • Consent receipt reference linking back to the Consent Receipt Token issued at sign time.

The attestation block is the artifact a future verifier (auditor, regulator, the user's lawyer) uses to verify the signature was applied with consent. It is the user's defense; not Hushh's.

4. Transparency Log entry

Every Signature Vault use lands in the user's Transparency Log. The user can reconstruct, at any time:

  • Every document signed
  • Every workflow that requested a signature (granted or denied)
  • The consent scope under which each signing happened
  • The verifier-presentable attestation block

The log is the user's, not Hushh's; Hushh holds the keys, not the contents.

"Sign once, use everywhere"

The user's signature is captured once — in the One KYC agent flow during onboarding — and then becomes invocable anywhere One mediates a workflow. Concretely:

  • KYC for iBrokerage, Plaid connections, brokerage account opening
  • Subscription documents, only when the relevant product, legal, and fund workflows are live and approved.
  • Research agreements and partner documents, only when the relevant partner workflow is consent-gated and audit-ready.
  • Any future PCHP-mediated workflow that reaches a "I agree" surface

The user never re-uploads their signature. The user never types their name in a "this is my signature" font. The user signs in the original sense — biometric-confirmed, cryptographically attested, fully audited.

Threat model — what Signature Vault defends against

  • Replay. Each attestation block contains a unique nonce; replaying a captured signature fails verification.
  • Forgery via stored-image extraction. AES-256-GCM with Secure Enclave binding means the encrypted signature is unreadable without the user's biometric on that physical device. Cloud breach does not compromise the signature.
  • Coerced signing. The user can revoke consent for an in-flight signing operation up until the moment of biometric confirmation. After that, the document is signed; revocation post-signature is a separate (much harder) workflow that requires re-engaging the counterparty.
  • AI-mediated misuse. When Kai mediates a signing operation (e.g., signing a partner MOU drafted in chat), the platform identifier in the attestation block makes it explicit that an AI was in the loop. The user can audit; the counterparty can audit; future regulators can audit.

What Signature Vault does NOT do

  • Does not replace notarization for legal instruments that statutorily require a notary.
  • Does not issue qualified electronic signatures under eIDAS (the EU regulatory regime for QES); meeting QES requires a qualified trust service provider, which is a separate engineering and compliance scope.
  • Does not become the user's identity. Identity is anchored on phone-number-plus-email per the One primary-identity-anchor model; the signature is one consented attestation surface, not the identity itself.
  • Does not sign things automatically. Every use requires fresh biometric confirmation. There is no "always sign documents that look like X" rule, and there will not be.

Counterarguments worth arguing with

  1. "DocuSign already exists." Response: DocuSign is a centralized service that holds its customers' signatures and documents. Signature Vault is the user-side primitive that lets the user sign any document — including DocuSign-mediated ones — with cryptographic attestation that the user controls. Different position in the stack.
  2. "This is overengineering for a personal-finance app." Response: the Signature Vault isn't built for personal finance. It's built for the Personal Operating Layer thesis — the user owns one signature, applies it everywhere their agent acts on their behalf. Personal finance is one downstream surface; sponsored-research, KYC, healthcare directives, identity proofs are the others.
  3. "AI-mediated signing is a regulatory minefield." Response: yes — and that is exactly why the platform identifier in the attestation block matters. Hushh's posture is that AI-mediated signing must be explicit and auditable, not hidden. Regulators who want to surface AI involvement can see it; regulators who want to ban it have a clean signal to act on.

What this is not

  • Not shipped. The pattern is documented and the cryptographic primitives are well-understood; full implementation tracks the One platform roadmap.
  • Not a generic e-signature service. Signature Vault is a One feature, not a standalone offering. Counterparties that want this primitive without the One platform get the open PCHP reference instead.
  • Not a substitute for legal counsel. Documents requiring signature are still reviewed through the proper legal workflow. Signature Vault automates the signing, not the deciding-to-sign.

Repo truth and north-star boundary

  • Current repo truth: Signature Vault is a north-star pattern unless a specific checked route, storage contract, test, and deploy evidence proves a shipped signature workflow.
  • North-star direction: signature use should be consent-gated, auditable, and bounded by vault authority.
  • Not shipped / not implied: partner systems must not store reusable signing secrets, vault keys, or broad signature material.

Sources

  • PCHP — consent primitives reused.
  • One — platform context.
  • Nav — consent and scope-review direction.
  • Internal Hussh signature-attestation rules — source for the consent-gated signing pattern.