+3

AGENTS.md

Reviewed

··· 49 49 - Passkeys are stored as account credentials: credential ID, public key, 50 50 signature counter, friendly name, and timestamps. Password login remains 51 51 available unless an explicit account policy changes that. 52 52 + - App passwords are account-owned credentials. Management requires password 53 53 + auth, generated passwords are shown once, and revoking a credential revokes 54 54 + active sessions created with it. 52 55 - Password sessions are storage-backed token families. Accept session JWTs only 53 56 when their JTI is active, and keep subject/actor/controller fields distinct in 54 57 account-plane audit work.

+6 -4

README.md

Reviewed

··· 4 4 5 5 > name credit: jim (`calabro.io`) suggested `zds`. 6 6 7 7 - `zds` stores atproto accounts, repos, records, blobs, sessions, oauth state, and 8 8 - identity state. it uses [`zat`](../zat) for protocol primitives: syntax, tids, 9 9 - did resolution, jwt helpers, dag-cbor, car, mst, repo verification, and key 10 10 - encoding. WebAuthn support comes from 7 7 + `zds` stores atproto accounts, repos, records, blobs, sessions, oauth state, 8 8 + account-security state, and identity state. it uses [`zat`](../zat) for 9 9 + protocol primitives: syntax, tids, did resolution, jwt helpers, dag-cbor, car, 10 10 + mst, repo verification, and key encoding. WebAuthn support comes from 11 11 [`webauthn`](https://tangled.org/zzstoatzz.io/webauthn). 12 12 13 13 ## docs ··· 107 107 Revocation also invalidates active sessions created with that app password. 108 108 - Passkeys are optional account credentials for the OAuth login page. ZDS stores 109 109 credential IDs, public keys, counters, names, and last-use timestamps. 110 110 + - `/security` is the local account-security page for passkey and app-password 111 111 + management. 110 112 111 113 ## references 112 114

+3 -1

docs/account-security.md

Reviewed

··· 46 46 `/security` is the local account-security surface. It signs in with the account 47 47 password, then lists passkeys and app passwords for that account. App passwords 48 48 can be created and revoked from the page; the generated password is displayed 49 49 - once and is not recoverable later because only the hash is stored. 49 49 + once and is not recoverable later because only the hash is stored. The 50 50 + privileged-app-password checkbox is labeled as trusted-client behavior because 51 51 + ordinary clients should not request it casually. 50 52 51 53 ## references 52 54

+7 -2

docs/architecture.md

Reviewed

··· 13 13 helpers, DAG-CBOR, CAR, MST, repo verification, OAuth helpers, and streaming 14 14 clients. 15 15 - `zds` owns PDS policy and persistence: accounts, repo writes, sessions, 16 16 - storage, server routes, sync production, account migration, and the local 17 17 - login/security surface. 16 16 + app passwords, passkeys, storage, server routes, sync production, account 17 17 + migration, and the local login/security surface. 18 18 - SQLite stores account, repo, commit, token, OAuth, blob metadata, and identity 19 19 state. 20 20 - Password sessions are durable rows keyed by access and refresh JWT IDs. Refresh ··· 72 72 by the local `webauthn` dependency and stored in SQLite. Discoverable passkey 73 73 login is supported so an account can be chosen by the authenticator during the 74 74 OAuth flow. 75 75 + 76 76 + `/security` is the local management surface for passkeys and app passwords. It 77 77 + uses account-password authentication for management actions, matching the 78 78 + official PDS boundary that app passwords cannot mint or revoke other app 79 79 + passwords. 75 80 76 81 PDS-owned `app.bsky.actor` preferences are handled locally because the official 77 82 PDS implements those routes. Appview reads and writes remain behind the generic

+7

docs/operations.md

Reviewed

··· 129 129 Migration requires working public HTTPS, stable JWT secret, email delivery, blob 130 130 storage, and writable SQLite storage. 131 131 132 132 + ## account security 133 133 + 134 134 + The local security surface lives at `/security`. It is for account-owner 135 135 + management of passkeys and app passwords and requires the account password for 136 136 + management actions. App-password revocation also revokes active sessions that 137 137 + were created with that app password. 138 138 + 132 139 ## conformance 133 140 134 141 Useful external checks:

+4 -3

docs/passkeys.md

Reviewed

··· 22 22 23 23 If the login hint resolves to an account with saved passkeys, the OAuth page 24 24 offers passkey login first and keeps password login available. If no passkey is 25 25 - saved for the account, password login is shown directly with a link to the 26 26 - security page. 25 25 + saved for the account, password login is shown directly and points the user to 26 26 + `/security` after authentication. 27 27 28 28 Discoverable passkey login is supported: the browser may return a credential 29 29 without the page first choosing an account. ZDS resolves the credential ID to ··· 34 34 35 35 Passkeys are managed from `/security`, alongside app passwords. That page signs 36 36 in with the account password, lists saved passkeys, and supports add, rename, 37 37 - and delete. 37 37 + and delete. Registration uses a browser WebAuthn prompt; ZDS stores only the 38 38 + credential ID, public key, counter, name, and timestamps. 38 39 39 40 Deleting a passkey removes it from ZDS. The browser, OS, or password manager 40 41 may still keep its copy, but it can no longer be used with this PDS.

+10 -2

docs/references.md

Reviewed

··· 59 59 - benchmark design and metastore comparisons 60 60 - delegation groundwork 61 61 62 62 + ### webauthn 63 63 + 64 64 + Link: [zzstoatzz.io/webauthn](https://tangled.org/zzstoatzz.io/webauthn) 65 65 + 66 66 + ZDS uses this local Zig WebAuthn library for passkey ceremony parsing and 67 67 + verification. Keep PDS policy in ZDS, but prefer moving general WebAuthn 68 68 + encoding, challenge, and signature-verification fixes into this library. 69 69 + 62 70 ### Pegasus 63 71 64 72 Link: [futur.blue/pegasus](https://tangled.org/futur.blue/pegasus) ··· 173 181 IDs, public keys, counters, names, and timestamps, and verify WebAuthN 174 182 assertions before authorizing OAuth requests. 175 183 - Account-plane security should be storage-backed. Sessions, refresh rotation, 176 176 - app passwords, OAuth grants, passkeys, and revocation are not merely JWT 177 177 - formatting concerns. 184 184 + app passwords, OAuth grants, passkeys, and revocation are durable account 185 185 + state, not merely JWT formatting concerns. 178 186 - Delegation-ready code should keep subject, actor, and controller identities 179 187 distinct even before user-facing account delegation exists. 180 188