Home / Articles / The passkey opens the vault / Versions / v1.2.0
The passkey opens the vault: what changed in v1.2.0
From v1.1.0 (2026-10-11, cd0dbdc22) to v1.2.0 (2026-10-11, f5bb932d6), paragraph by paragraph.
6 paragraphs added, 0 removed, 2 changed in place, 76 unchanged. About 672 words added and 0 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
13 unchanged paragraphs, under In short {#short}
• Support is good enough to build on.on, and where the passkey lives decides what the reader gets.** PRF works in Google Password Manager, iCloud Keychain (Safari 18 and macOS 15), Windows Hello (since February 2026) and Firefox. WhereA itsynced doesprovider not,or a hardware key gives the same newsroom on every device; a clean browser with neither gives one device plus the recovery code, and Chrome's own store returns no PRF bytes at all, so the page sayschecks soat creation and offers thea recoveryladder code.of alternatives.
44 unchanged paragraphs, under Part one: the design {#design}
### What happens in a clean browser {#clean}
The table above is about browsers. The question that matters to a reader is about devices: will the newsroom I opened on my laptop be the same one on my phone? That depends on where the passkey lives, which is a choice the reader made long before they met this site, usually without noticing.
[figure pk-where.webp] Where a passkey can live, what each place needs, whether the passkey travels, whether it can return the PRF bytes, and what that means for the reader. The ladder below the table is what the page offers when PRF is off.
| Where the passkey lives | Needs | Travels? | PRF | What the reader gets |
|---|---|---|---|---|
| Google Password Manager (Chrome signed in, Android) | A Google account | Yes, to every device signed in to it | Yes | The same newsroom everywhere |
| iCloud Keychain (Safari, iPhone, iPad, Mac) | An Apple ID | Yes, across Apple devices | Yes, Safari 18 and macOS 15 | The same newsroom on every Apple device |
| Windows Hello (Windows 11) | The device; a Microsoft account to sync | Device-bound, unless synced | Yes, since February 2026 | This PC, or every PC on the account |
| A hardware key (YubiKey and others) | The key, and its PIN | Yes, wherever the key is plugged in | Yes, through hmac-secret; not with YubiKeys in Safari | No account anywhere; a few dozen passkeys per key |
| Your phone, by QR (the hybrid flow) | A passkey on the phone, in its own provider | Yes, one scan at a time | Where the phone's provider does | A clean laptop opens with the phone beside it |
| Chrome's own profile store (a clean Chrome, no provider) | Nothing | No: this browser, on this computer | No, in 2026 tests | Signs, returns no bytes: the door cannot be derived |
So the rule, in one line: the same newsroom on every device needs a synced provider or a hardware key in your pocket. A clean browser with neither gives you this device, plus the recovery code. A passkey made there still works, as a passkey; it is stored by the device, tied to that browser profile on that computer, and deleted with it. The catch for this design is the last row: Chrome's own store, used when there is no provider (a clean Chrome on Linux, or on a Mac with iCloud Keychain off), signs but returns no PRF bytes in 2026 tests, so the door cannot be derived there at all.
Two things follow. The page learns which case it is in at creation, from prf.enabled, and never guesses. And when PRF is off, it offers a ladder, in this order: sign in to a provider, so the passkey syncs from now on; use your phone by QR, one scan at a time; plug in a hardware key; or stay on this device, where the browser's own copy keeps working and the recovery code is the way back. That is a real limitation of PRF today, not of the design, and the article would be dishonest without it. One caveat on the Chrome-profile row: it comes from a vendor's published tests, so the brief includes a five-minute check on a clean profile before anyone depends on it.
2 unchanged paragraphs
1. No sign-in. The first screen is the passkey. Google sign-in is a later phase, on its own origin, and only for what it is good for: continuity for support, 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. When it is false, the ladder: sign in to a provider, your phone by QR, a hardware key, or this device only with the recovery code, each explained in one line.
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 vaults, taken from the vault web app and 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; a clean Chrome profile with no provider, to confirm what its own store returns for prf.enabled and that the ladder appears; 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.
17 unchanged paragraphs, under Part two: what this enables {#enables}, What this does not claim {#limits}, Where this comes from {#sources}