Issue, hold, encrypt, share, and cryptographically verify W3C Verifiable Credentials with self‑sovereign Decentralized Identifiers (DIDs), client‑side Encrypted Data Vaults, and Authorization Capabilities (ZCaps) — built entirely on open standards.
Live: webwallet.one-ai.us
WebWallet is a reference implementation of the Digital Credentials Consortium (DCC) architecture: a credential wallet where the server never sees your data in the clear. Credentials are signed by their issuers, encrypted on your device, and stored only as ciphertext. Your keys are derived from a passphrase and never leave the browser — so only you can read what's in your wallet.
WebWallet is developed as a collaboration between the Digital Credentials Consortium (DCC) and OneOrigin — pairing the DCC's open credentialing standards with OneOrigin's product engineering.
This is not a mockup. A live API and a real database back every screen; the cryptography is genuine (Ed25519 signatures, X25519 key agreement, XChaCha20‑Poly1305 encryption), and verification actually checks the math.
- 🪪 Self‑sovereign identity — a
did:keyidentifier plus an Ed25519 signing key and an X25519 key‑agreement key are derived locally from your passphrase. - 📜 Verifiable Credentials — import W3C VCs by JSON, file, or QR, or issue new ones.
- 🔐 Zero‑knowledge storage — every credential is encrypted (XChaCha20‑Poly1305 + ECDH‑ES) to your key before it's persisted. The database holds only ciphertext.
- 🧠 Skills — competencies extracted from your credentials and mapped across categories, plus skills you add yourself.
- 📎 Attachments — attach supporting files to credentials.
- 🗂️ Bundles — group multiple credentials and share them with a single link.
- 🔗 Sharing — generate time‑bound public links or QR codes; revoke instantly.
- ✅ Cryptographic verification — check a credential's real Ed25519 signature, issuer DID, expiry, and StatusList revocation. Unsupported proofs are shown as unknown — never a faked pass.
- 🛡️ Holder‑scoped by construction — every record is bound to your DID; cross‑wallet reads are rejected (HTTP 403).
- 🏛️ Open Badges 3.0 and ZCap delegation primitives included.
browser ──▶ Next.js 15 (App Router) apps/web
│ │ Web Crypto: passphrase → keypair, client-side decrypt
│ ▼
└─ same-origin /api/* ──▶ Hono on Node 22 apps/api
│ ZCap auth · holder isolation · Zod validation
▼
SQLite (better-sqlite3) encrypted blobs only
packages/crypto ── Ed25519 · X25519 · EDV (JWE) · did:key · ZCaps · OB3
packages/types ── shared DTOs
packages/ui ── shared React components
Layered concepts
| Layer | Responsibility |
|---|---|
| DID | did:key identifier + Ed25519 controller key + X25519 keyAgreement key |
| EDV | Client‑side JWE envelopes — XChaCha20‑Poly1305 + ECDH‑ES key wrap |
| WebSpaces (WAS) | Spaces → Collections (privateCredentials, publicCredentials, walletActivity) → encrypted Items |
| ZCap | Every access is an authorized capability invocation |
| VCALM | DIDAuth + VP request/response exchange between issuer ↔ holder ↔ verifier |
| Layer | Choice |
|---|---|
| Monorepo | Turborepo + pnpm workspaces |
| Web | Next.js 15 (App Router) · Tailwind v4 · framer‑motion |
| API | Hono on Node 22 (@hono/node-server) |
| Database | SQLite (better-sqlite3) — embedded, zero‑ops |
| Crypto | @noble/curves, @noble/hashes, @noble/ciphers (audited, ESM‑first) |
| Validation | Zod at every boundary |
pnpm install
pnpm rebuild better-sqlite3 # if the native build was skipped
pnpm dev # web (:3010) + API (:4000) in parallel
# or individually:
pnpm --filter @dips/api dev
pnpm --filter @dips/web dev
pnpm typecheck # all packages
pnpm --filter @dips/api test:e2e # full API end-to-end suite
pnpm build # production buildOpen http://localhost:3010 and choose Enter demo wallet to explore with seeded, real, signed credentials.
- Encrypted at rest — credentials are sealed to your X25519 key before storage; the server cannot decrypt them.
- Keys stay on device — derived from your passphrase via PBKDF2‑HMAC‑SHA512; never transmitted. Ed25519 (signing) and X25519 (encryption) are kept distinct — no in‑place ed→x conversion.
- Holder isolation — every credential, skill, attachment, and bundle is scoped to the
caller's DID; cross‑DID access returns
403. - Honest verification — signatures are genuinely checked; the wallet never reports a pass it can't prove.
- Hardened API — pinned CORS allowlist, security headers (CSP, HSTS,
nosniff,X-Frame-Options), rate‑limiting on auth/recovery flows, and a requiredSESSION_SECRETin production.
.
├── apps/
│ ├── web/ Next.js 15 wallet UI
│ └── api/ Hono + SQLite API
├── packages/
│ ├── crypto/ Ed25519 · X25519 · EDV · ZCaps · did:key · OB3
│ ├── types/ shared TS DTOs
│ └── ui/ shared React components
└── LICENSE MIT
MIT © 2026 Digital Credentials Consortium (DCC)