blog · mera prf · 2026-10-01

One passkey, four keys, nothing stored

A passkey can do more than sign in. Its PRF output is deterministic key material, so one ceremony seeds a family of unrelated keys that reconstruct anywhere, with nothing kept on a disk or a server.

the primitive: deterministic key material from a passkey

WebAuthn PRF returns the same bytes every time for the same passkey, relying party and salt. That is the whole lever. Change the salt and you get an independent output, so one passkey is a root for as many unrelated keys as you have salts. Category Labs, who build Mera, confirmed the part that makes this safe to lean on: because the output is deterministic, the keys are recoverable on any device holding the same passkey, with no separate enrolment and no keys cached in the browser.

four namespaces from one ceremony

We run one PRF ceremony, then split it with HKDF-SHA256 under a fixed salt, with a different info string per key. The info string is the namespace, so the four keys are cryptographically unrelated even though they share one root.

account
kanmani.iris.v1 · secp256k1, the address that pays and owns
attestation
kanmani.optic.v1 · ed25519, a did:key that is not a wallet
on-chain attestation
kanmani.optic-onchain.v1 · secp256k1, recoverable by ecrecover
content
kanmani.vitreous.v1 · AES-256-GCM, encrypts stored data

Signing keys are derived and content uses an AEAD. The two are never confused. The derivation is pinned by a test vector so two implementations agree: PRF bytes 1 through 32 give the account address 0x92c2…454B every time.

nothing is stored, which is the whole point

No cookie, no token, no cached credential id, no derived private key on disk. The passkey is discoverable, so the browser offers it unprompted and there is no returning-user record to leak or to break. A test fails if any derived secret ever reaches local storage, session storage, IndexedDB or the server. The one thing we do keep on a server is a vault blob encrypted under the content key, with the context bound as additional authenticated data, so untrusted storage holds ciphertext and nothing that could decrypt it.

the novelty: a receipt signed by an identity that is not a wallet

The attestation key signs verification receipts. Anyone can check one against the public endpoint, so its output is public evidence produced by an identity that holds no funds and is not an account. That is the furthest thing from a passkey wallet, which is the point of the primitive: a PRF namespace doing non-account work.

The account page shows the four key fingerprints, signs a receipt in the browser and verifies it against the public endpoint. It also holds a compare box so a second device can prove it reconstructs the same keys and decrypts the same blob.