Home / Articles / The passkey opens the vault / Versions / v1.1.0
The passkey opens the vault: what changed in v1.1.0
From v1.0.0 (2026-10-11, 4dc636a97) to v1.1.0 (2026-10-11, cd0dbdc22), paragraph by paragraph.
2 paragraphs added, 1 removed, 18 changed in place, 58 unchanged. About 452 words added and 59 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
# The passkey opens the vault: sign in with Google, touch a passkey, and a master vault for every user, with no server of oursours, no account and no email
Summary: The missing piece of the client-side puzzle is a user who can open their own vaults on any device, in a few seconds, with nothing to remember.remember and nothing to sign up for. This is the design. Sign in with Google says who you are. A passkey, through the WebAuthn PRF extension, gives the browser 32 bytes that only your authenticator can produce for this site, and from those bytes the browser computes the key of a small door vault, which holds the key of your master vault, which holds the keys of everything else, starting with your newsroom vault. There is no sign-in: the page makes and uses the passkey through the browser's own API, with no Google app, no OAuth and no server, and it never learns your email or your name. The question I could not answer, where the encrypted vault key is stored, has a simple answer: nowhere. sgit vault keys are made in the client, so the door's key and its id can be computed from the passkey on any device, before anything is fetched, and there is no chicken and egg. A recovery code makes a second door to the same master. Google holds no key; its Drive app-data folder can keep a backup. PRF is now supported by Google Password Manager, iCloud Keychain, Windows Hello and Firefox. The unlock costs up to six key derivations, measured. The first part is the technical design and the brief for the MVP on newsroom.sgit.ai, end to end; the second is what it enables: accounts with no server,server and no identity, for this site and for any other.
!shot pk-chain.webp | images/ | The key chain. Sign in with Google says who you are. The passkey's PRF output derives a door vault, the door holds the master vault's key, and the master holds the keys of everything else. Nothing secret is stored anywhere to be fetched, and the vault server sees ciphertext at every step.
1 unchanged paragraph
The experience I want is simple. I open newsroom.sgit.ai in a new browser. I sign in with Google. I am asked to touch my passkey. And my reading account opens, the same as on every other device, because it is now in a vault only I can open. ThreeTwo steps, one of them a gesture, and no server of ours anywhere.anywhere, and nothing to sign up for.
2 unchanged paragraphs, under In short {#short}
• Sign in with Google says who you are; it does not open anything. It gives the browser a stable account id, with no server of ours, and ties what you bought to you. It never holds a key.
• No sign-in, no account, no email. The page makes and uses the passkey itself, through the browser's WebAuthn API: no Google app, no OAuth loop, no server. The reader's passkey provider syncs it between their devices; the site never learns who they are.
• That is a privacy feature, with a price. We cannot email the reader, and there is no "forgot password": recovery is the recovery code and a second passkey. A purchase has no identity to hang on. I think it is the right trade.
5 unchanged paragraphs
• One rule the design depends on: the pagewhole that holds the keysorigin loads no third-party scripts, Google'son included.any Sign-inpage, happensbecause browser storage is per origin and a script on itsone ownpage page.can read what another page kept. The vault code is vendored into the reader repository, not loaded from anywhere else.
4 unchanged paragraphs, under Part one: the design {#design}
| Piece | What it gives the page | What it does not give |
|---|---|---|
| Sign in with Google (later, optional, on its own origin) | An ID token withContinuity: a stable account id andfor ansupport, email,a inDrive thebackup, browser,a through Google Identity Services; optionally an access tokenreference for one narrow Drive scopepurchases | Any key. GoogleIt sign-inis alonenot opensin nothingthe MVP and not needed to open anything |
| A passkey for this site | A gesture (touch, face, PIN), a signature, and with PRF, 32 bytes computed from a secret the authenticator keeps for this site and this passkey | The bytes to anyone but the page on this site that asked, after the gesture |
| The passkey provider | Sync: Google Password Manager across your Chrome and Android devices, iCloud Keychain across your Apple devices, or none (a hardware key) | Anything about what the bytes are for |
| sgit | Vault keys made in the client (a 24-character passphrase and an 8-character vault id), read and write keys derived from them, ciphertext on the server | A way to find a vault you have no key for |
| The access key | The right to create vaults and write to them on the vault server, the thing people will buy | Any way to read a vault |
One clarification that matters. WhenWhat Ipeople saycall "the Google passkey", what the page usespasskey" is a passkey for this site, registered by this page under this site's name, which your provider stores and syncs.syncs: IfGoogle Password Manager if you use Chrome, thatiCloud providerKeychain ison GoogleApple Password Manager.devices. It is not the passkey you use to sign in to Google itself,Google, and a website cannot get PRF bytes from that one. SignThere is no sign-in in this flow at all: the page registers a discoverable credential with Googlea random user handle, and the passkeyonly arelogin twoinvolved separateis steps,the for two separate jobs: whoone you are,already andhave whatwith youyour canpasskey open.provider, which syncs it. The site learns a credential id, a public key and, after your gesture, 32 bytes. Not your email, not your name, not which account syncs it.
5 unchanged paragraphs
• Google Drive's app-data folder: this is the "application data" I had in mind. It is a private, hidden folder per app in the user's own Drive, reached with the drive.appdata scope, which Google lists as recommended and non-sensitive. It works from the browser, with the user present for each token. AIt goodneeds placeGoogle sign-in, which the MVP does not have, and it only helps if what it holds is wrapped under something other than the passkey: wrapped under the recovery code, it is a second copy of the recovery door, useful if the vault server loses data, and no help for a backup,lost butkey. itA makeslater Googleavailability partbackup, ofnot everythe unlock.main path.
6 unchanged paragraphs
1. The PRF input is a fixed, public value: SHA-256("newsroom.sgit.ai/door/v1"). An input is not a secret; only the authenticator can turn it into the 32 bytes.
2. The door seed is HKDF-SHA256(ikm = PRF bytes, salt = SHA-256("newsroom.sgit.ai"), info = "sgit/door/v1").
3. The door's passphrase and vault id are two more HKDF outputs from the seedseed. sgit accepts any printable ASCII passphrase up to 256 characters, so the passphrase is the hex of 32 bytes (info = ".../passphrase"".../passphrase"), andkeeping ".../id"all ),mapped256 bits. The vault id has to sgit's alphabet ofbe lowercase letters and digitsdigits, 4 to 24 of them, so 8 characters are drawn from a third output (info = ".../id"`) with rejection samplingsampling, so that no character is favoured: 24 characters and 8.favoured.
4. The door vault key is the sgit vault key made of those two, and from there, sgit's own derivation gives the read and write keys, exactly as the command line does.does: PBKDF2-HMAC-SHA256 at 600,000 iterations, once for the read key and once for the write key. That is the cost of this design. Door, master and newsroom vault need up to six derivations; measured in headless Chromium on a four-core machine, one takes about 105 ms and six run together about 640 ms, and a phone is several times slower, so a cold unlock can spend two to four seconds deriving keys before it fetches anything. The brief measures it on a phone, derives each vault's keys once per session, runs them in a worker, and derives a write key only when there is something to write.
5. The recovery door is the same, with the recovery code in place of the PRF bytes: 26 characters of base32, 128 bits, made by the page and shown once. It is long so that it needs no password stretching, as in the secrets.sgit.ai keyring design.
6. Collisions are not a practical worry with 36⁸ possible ids, but the page checks: a derived id that already holds something it cannot open is skipped, with a counter in the HKDF info.
6 unchanged paragraphs
!shot pk-flows.webp | images/ | The first run, a new device, and adding a passkey or recovering. Every step runs in the browser, against Google for sign-in, the user's passkey provider for the gesture, and the vault server for ciphertext.
First run. Sign in with Google. Create a passkey for the site with prf enabled; if the authenticator cannot do PRF, the page says which kinds can and offers another. Touch it: the PRF bytes give the door. Generate the master key, the newsroom vault key, a key pair and a recovery code. Paste the access key. Create the door, the master, the newsroom vault and the recovery door. Move the reading account from the browser's storage into the newsroom vault. Show the recovery code once, behind "I have written it down".
A new device. Sign in with Google. Touch the passkey, synced to this device or used from a phone by QR. The PRF bytes give the same door, the door gives the master, the master gives the newsroom vault. Reading needs no access key; the access key comes out of the master, so this device can write as well. Merge this browser's reading into its own log.
4 unchanged paragraphs
• What each party sees. The vault server: ciphertext, sizes, times and ids that look random. Google: thatnothing, youin signedthe in.MVP. Your passkey provider: that a credential exists for this site. Only this page, in your browser, after your gesture, holds the PRF bytes and the keys.
• The page that holds the keysorigin loads no third-party scripts.scripts, Thaton includesany Google'spage.** Storage is per origin, so a script on a sign-in library:page could read what the account page keeps. If sign-in with Google is added later, it runs on an origin of its own page,and whichhands passesback an account id; the newsroom's pages load only thecode account id onwards, andfrom the pagereader thatrepository, unlockswith loadsthe nothingvault code vendored into it didrather notthan build.loaded from the vault web app or tools.sgraph.ai.
11 unchanged paragraphs
1. SignNo insign-in. withThe Google,first screen is the passkey. Google sign-in is a later phase, on its own page,origin, with Google Identity Services in the browser. Keepand only thefor accountwhat idit andis email,good for: continuity for thissupport, session.a Drive backup, a reference for purchases.
2. The passkey: create with rp.id = newsroom.sgit.ai, a resident key, user verification required, extensions.prf; get with the fixed PRF input; check prf.enabled.
3. The derivation in part one, with test vectors shared with the sgit command line.
4. The vaults: door, master, newsroom and recovery door, created with the access key, using the browser code that already reads and writes vaultsvaults, (thetaken from the vault web app and tools.sgraph.ai).tools.sgraph.ai and vendored into the reader repository.
5. The move: the reading account from the browser's storage into the newsroom vault, as the first device's log.
6. The right-hand side: once open, show the vault: the master's list of vaults and doors, and the newsroom vault's contents, so the user can see what is kept and where.
7. Tests: Chromium's virtual authenticator with PRF in the build (secrets.sgit.ai found it works in Chromium 141); the first run, a new device and the recovery code, end to end; two devices editing offline and agreeing; a synthetic reader who has never heard of a vault key.
8. Not in the MVP: Google sign-in, the Drive backup, sharing across sites, anything on a server of ours.
The acceptance test is the experience in the second paragraph of this article: a new browser, Google, a gesture, and my reading account, on my iPhone, my iPad, my laptops and my iMac.
2 unchanged paragraphs, under Part two: what this enables {#enables}
• Accounts with no server.server, and no identity.** A static site gets a user who can sign in, open their own data on any device, and keep it private from the site's operator. No account database, no password, no email, no back end.
12 unchanged paragraphs, under What this does not claim {#limits}, Where this comes from {#sources}
A voice memo of mine, recorded on 11 October 2026, asking for the design and for research into what a passkey gives a website and where an encrypted vault key could be kept; written by this site's agent in the voice of this site. The argument and the editorial responsibility are mine. The design builds on secrets.sgit.ai's published design (how it works, the keyring format, passkeys, WebAuthn and PRF and keys), and on how sgit generates and parses vault keys in the client (generate_vault_key and parse_vault_key in the sgit command line).line); the unlock cost was measured with WebCrypto PBKDF2 in headless Chromium on 11 October 2026. The research: Corbado, Passkeys and WebAuthn PRF for end-to-end encryption (2026) and WebAuthn L3 support in credential managers; Yubico, Developer's guide to PRF; Mozilla, support for the WebAuthn PRF extension; Chromium, intent to ship the PRF extension; web.dev, passkey reuse across sites with Related Origin Requests; Google, choosing Google Drive API scopes and authorising for the web. Related articles: I miss it, so it is working, No server, by design, Where the vault keys live, RFC 0001 and How to run synthetic users.