An EU-Wallet holder that lives in your browser.

Why a browser wallet at all?

How you sign in

The wallet is gated by our own OIDC provider — the same sign-in that protects every other admin surface. There is no separate "wallet account"; there is one identity per tenant. When you open /web-wallet.html you are prompted to sign in (WebAuthn, TOTP, or password, per tenant policy) and every request the wallet makes to /wallet-backup.ashx carries an OIDC bearer token.

Two layers, each doing its own job. Authentication (OIDC, "who are you") gets you access to the encrypted vault blob. Vault decryption (passphrase or WebAuthn passkey PRF, "what unlocks your credentials") is independent of authentication and never leaves your browser. Zero-knowledge is preserved: the server knows who you are but still cannot decrypt your credentials.

Multi-factor recovery (from day one)

Losing your device shouldn't mean losing your credentials. The wallet stores an end-to-end encrypted vault that can be unlocked by any single registered recovery factor.

Factor 1 — Recovery passphrase (mandatory)

PBKDF2-SHA256 with 600 000 iterations (OWASP 2023) derives a key-encryption-key from your passphrase. The passphrase never leaves your browser. Write it down — it is the cold-storage fallback for the worst case.

Factor 2 — WebAuthn passkey (recommended)

Register a passkey with the WebAuthn PRF extension. The PRF derives a deterministic key-encryption-key per authenticator. On modern browsers (Chrome, Edge, Safari 17+, Firefox 122+) the passkey syncs via iCloud Keychain / Google Password Manager / Windows Hello, so a new device recovers your wallet with just the passkey ceremony — no passphrase entry needed.

Factor 3 — Multi-device passkeys (belt-and-braces)

Register additional passkeys on other browsers or devices. Each factor wraps its own copy of the vault's data-encryption-key. Add, remove, or replace factors at any time without re-encrypting the vault.

Zero-knowledge server backup

The wallet syncs its encrypted vault blob to your tenant's /wallet-backup.ashx endpoint (OIDC-bearer gated). Our server stores ciphertext only. We literally cannot decrypt your vault, use your keys, or help you if you lose every recovery factor. That is by design (zero-knowledge) and stated plainly in the setup wizard.

Envelope encryption: a random 256-bit data-encryption-key (DEK) encrypts your credentials with AES-256-GCM. The DEK is wrapped once per registered factor using AES-KW (RFC 3394). Passphrase factor: DEK wrapped under PBKDF2-derived key. Passkey factor: DEK wrapped under an HKDF-SHA256 derivation of the WebAuthn PRF output. Any surviving factor unwraps the DEK and decrypts the vault.

Supply-chain resilience: Aloaha-owned code

The entire EUDI protocol layer — SD-JWT VC parsing, KB-JWT signing, OID4VP presentation, OID4VCI credential import, wallet attestation, WebAuthn PRF integration, envelope encryption — is written line-by-line by Aloaha Limited in Malta. Zero eudi-lib-* dependencies in the tree. Zero openid4vc-* library adapters. Generic infrastructure libraries used elsewhere in the platform are well-established open-source components documented in our SBOM; the EUDI protocol layer is 100% ours.

Why this matters under the Cyber Resilience Act. Regulation 2024/2847 calls SBOM the minimum — “at the very least the top-level dependencies”. The Log4Shell-class of attacks lives in transitive dependencies that a standard SBOM does not surface. Our architectural response was to remove the supply chain for the parts that matter: a Log4Shell in the EUDI stack requires an EUDI supply chain to exploit, and we deliberately do not have one. Machine-readable SBOM: /sbom.spdx.json. Full rationale: cyber-resilience.html § 01.

Share-QR — scan-and-verify without installing a wallet

The wallet holder taps Verify (QR) on any credential. The full SD-JWT VC is POSTed to a per-tenant relay /vshare.ashx, which stores it under a 128-bit random opaque id and returns a short link. The QR encodes only that short link (~120 bytes), so it scans reliably from a phone screen across the room. The verifier fetches the credential by id, parses it in the browser, and shows a physical-mimic ID card with the disclosed attributes and a green VALID / red INVALID cryptographic status. Anyone with a phone camera can verify; no wallet app required.

Try it now — scan or click

Two live demo credentials. Scan a QR with your phone camera, or click it if you’re on a laptop. No wallet app required — the verifier opens in your browser and cryptographically checks the SD-JWT VC.

John CITIZEN

EU Digital Identity Wallet — Identity Card (PID)

Instead of scanning you can also click the QR to open the verifier directly.

Erika Mustermann

EU Digital Identity Wallet — Identity Card (PID)

Instead of scanning you can also click the QR to open the verifier directly.

Standards + interoperability

How it fits alongside the native EUDI Wallet

When the government-notified EUDI Wallet Instance for a Member State ships, users who want LoA-High and hardware-anchored PID belong there. This browser holder complements it, not competes with it. Use it for the audience the native app doesn't reach: older users, corporate desktops, first-touch onboarding, sector-specific credentials where LoA-Substantial is fit-for-purpose, or as a fallback when the native app isn't installed yet.

Read next

• Verifier live demo (OID4VP 1.0 FINAL)
• HAIP conformance evidence
• Age verification demo
• Verify a wallet credential (Share-QR public verifier) — scan a wallet-holder's Verify-QR from any phone camera; checks signature + expiry + disclosures + status-list bit entirely in the verifier's browser.
• Membership cards cookbook — tenant playbook for issuing member VCs into wallets and verifying them at the door.
• Machine-readable /openapi.json