The web console

An organisation's admin may never have installed the app, and needs a page to manage a team from. The console is at /org, and it signs in with a passkey: there is no password anywhere in it. It is a thin page over the Teams API (it calls /v1/teams and /v1/channels with its session), so it enforces exactly the roles the API does.

Setting it up (from the app, or any client holding the account key):

curl -X POST https://nowlark.com/v1/web/pairings -H "Authorization: Bearer nla_…"
# {"code":"npc_…","url":"https://nowlark.com/org/pair#npc_…","expires_at":1789665612}

Open url in the browser you want to sign in on and choose Create a passkey. The code is single use, lasts 10 minutes, is kept only as a hash, and rides in the URL's fragment, which a browser never sends to a server, so it is in no access log and no Referer. Afterwards that browser (or any browser or device that has the passkey, including one synced by iCloud Keychain) signs in at /org/login with no username. More passkeys can be added from a signed‑in browser at /org/passkeys; the last one cannot be removed (pair again from the app if all are lost).

What a session may do. Reach the team and channel routes, and nothing else. It cannot read /v1/me, list or make keys, rotate a key, redeem a pass or delete the account: those accept an account key only, so a stolen cookie is a team admin's session, never the account. Changes made with a session must carry its CSRF token (X-CSRF-Token, from GET /org/api/session) and an Origin of this site; the cookie is also HttpOnly, Secure and SameSite=Strict. A session ends after 2 hours idle or 8 hours in all. Rotating the account key with revoke_others (the lost-phone case) ends every session and removes every passkey.

Why it can be trusted: the challenge, origin, relying party id, user verification and signature are verified by the webauthn library; the server adds that a challenge answers exactly one ceremony (a captured response cannot be replayed, even from an authenticator that keeps no counter), that the signature counter never goes backwards (a copied credential), that the user handle in an assertion is the one stored, and that every sign‑in failure looks the same. Registration and sign‑in require user verification and a discoverable credential. The pages carry a Content-Security-Policy with no inline script and no unsafe-eval, and put every name on the page as text.