LIVE cartercole.net --:--:-- UTC

// 01 ACTIVE SYSTEMS

kith

RUST TYPESCRIPT PYTHON REPO SPEC

One identity, many keys. Each person gets a single self-certifying root, a did:kith backed by a signed key event log, controlled by a policy over every signer they already have: passkeys, hardware keys, Ethereum wallets, SSH keys, software keys. Applications never see any of that. The hub is a standard OpenID Connect provider, so anything that can "Sign in with…" can sign in with Kith and gets an ordinary JWT back. A draft spec in ten parts with shared conformance vectors, and reference implementations in Rust, TypeScript and Python.

> The touron YouTube1:23
Three windows of a local Kith hub's sign-up page, at localhost:4421/signup, in dark mode. First, 'Create an account': your account is a passkey on this device, there is no password to forget and the site never holds your keys, with the passkey named Ada's laptop and a Continue button. Second, the recovery key step: 'First, set up your recovery key', with a choice of a file made for you, a key derived from your own secret words, or the public half of a key you already have; the file option chosen, a Download recovery key button, the resulting did:key shown, 'I saved it somewhere safe' ticked, and a Create passkey button. Third, 'Your account is ready', the new did:kith identity, and an optional proof-of-work box that has spent about 20 bits of browser compute on the account, with Resume and Continue buttons and 'Account created.' 01 An account: a recovery key first, then a passkey Two windows of the same local hub. Left, at /oauth/authorize: 'Sign in to Demo App', use a passkey on this device or a security key, a Sign in with a passkey button, 'No account yet? Create one' and a folded 'Other ways to sign in'. Right, at /oauth/consent: 'Demo App wants to know who you are', listing what localhost will receive, your Kith identity (a did:kith) and your name (not set), with Allow and Deny buttons, and a note that Kith remembers this choice for the app 02 Sign in with Kith, from any OpenID Connect app Two windows of the local hub. Left, /whoami: 'You're signed in', the identity, and this sign-in made with a passkey at assurance level 2, multi-factor; the device, a passkey signed in here; when the account was created; email none; work 20 bits; with Add a device and Sign out buttons, and a note that a computer joins from its terminal with kith device join --hub http://localhost:4421. Right, after Add a device, a /join page: 'Add a phone or another device', scan this with the phone's camera, the phone makes its own passkey and you approve it here, with a QR code of the join link and a button to make the passkey on this device instead 03 Adding a phone is a QR code A terminal: kith --home ada init --keystore file creates a did:kith identity with one software device at aal 1 and 2-of-3 recovery keys, warning that the keys are in plaintext at ada/identity.json; kith device add --name phone --kind passkey exports a passkey device to phone.json, kith --home phone device import brings it to another home, and a login from there is aal 2 with amr hwk, roles billing-admin and billing-reader; the key event log shown through jq as two events, inception with this-device and add_device with phone, each carrying two signatures; and kith work --bits 24 mining a nonce at 19.6 million hashes a second on 16 threads, which the hub records as 28 bits 04 One root, a second device, every change in the log A terminal: kith login --aud api://invoices with the device key alone is aal 1, amr swk, groups finance and staff, role billing-reader; the same login with --totp and a six-digit code is aal 2, amr swk, otp and mfa, adds the dynamic group strong-auth and the role billing-admin; then kith token piped through a jq helper called claims lists the access token's claims one to a line: iss http://localhost:4421, sub the did:kith, aud api://invoices, iat, exp, jti, groups, roles, attrs with email ada@example.com, name Ada, department finance and work, aal 2, amr, and dev, the device that signed in 05 A TOTP code adds a role A terminal against a second local hub that issues tokens from an organization's policy DAG: Acme, an organization that is just another identity, runs kith policy publish, which prints the root CID and 'published 19 blocks; policy root committed at kel seq 1', then policy add-revoker lets the hub sign revocations and heartbeats for Acme and nothing else; kith policy slice for Query.invoices returns two policies, list-invoices and no-delegated-mutations, four sets and a proof of 9 blocks and 2911 bytes; Ada logs in with groups finance and staff and role billing-reader; Acme runs kith revoke member Ada Group::finance and revocation 1 is pushed; kith revocations reports freshness level fresh, age 3 seconds, at seq 1, with a drand round number; and Ada's next login has groups staff only and no roles 06 Revoked, pushed, and gone from the next token

The root and what hangs off it

Keys cascade: the identity authorizes devices, a device mints short-lived session keys, and a session can delegate a narrow slice of itself to someone else. Different changes need different quorums (two of three passkeys to add a device, the cold recovery keys to rotate the root), and the key event log records each one, signed, so anyone can replay how an identity came to hold its current keys without trusting the server that stores it.

On a Mac the CLI keeps the identity's keys in the login keychain and the device's own key in the Secure Enclave. A terminal joins an identity with kith device join; a phone joins by scanning the QR code the hub's account page shows under Add a device. Either way the new device waits until the identity's manage policy approves it.

Signing in

Evidence goes in and a JWT comes out. The hub accepts a device session chain, a signed challenge in the style of Sign-In with Ethereum, a passkey, or a TOTP code for step-up, and issues a token whose aal and amr claims say how strong that evidence was.

Over OpenID Connect that becomes a PKCE code flow with username-less passkey login, SSO, step-up through acr_values and pairwise subjects, so Auth.js, Django allauth, oauth2-proxy and Grafana use it unchanged. With --signup, anyone can make an account in the browser: a recovery key first, of which the hub only ever receives the public half, then a passkey. Signing in with a provider such as Telegram first works too. The hub behind this site's analytics console runs at accounts.cartercole.net.

Authorization

Cedar policies, with explicit, nested and dynamic groups and roles. A dynamic group is a proposition, such as "in finance, and signed in at AAL2". The engine plugs into GraphQL at the root, field and row level in Node and Python, and root fields are denied unless a policy allows them.

An organization publishes its policies as a content-addressed DAG of IPFS-compatible blocks, and its key event log commits to the root. A server answering one GraphQL field fetches only that field's policies, from anyone, and can prove nothing was left out.

Revocations that can prove how fresh they are

Revocations are pushed as a signed, hash-chained list, with heartbeats that embed a drand or NIST beacon round. A heartbeat could not have been signed before its beacon was published, so its age is proved rather than claimed. Each verifier states how long it can go between syncs (fresh, then degraded, then it fails closed), and a policy can demand more: under sixty seconds for a payment, say. OpenTimestamps anchors the whole history to Bitcoin.

Also in the box

Stated honestly

This is a draft spec with a working reference implementation, and it is not production ready. On Linux the CLI keeps keys in plaintext, the hub has no TLS of its own, GPG signers are specified but not implemented, and Bitcoin signers are planned. brew install cartercole/tap/kith installs the CLI and the hub, and each release carries archives for macOS and Linux on ARM64 and x86-64.

About these pictures

figures/kith.sh in this site's repository draws all six from the 0.3.0 release, built from its tag, against throwaway hubs on this machine. Every identity, passkey, recovery key and TOTP secret in them was made for that run and thrown away after it. The pages were driven in headless Chrome with a virtual authenticator standing in for the passkey. The CLI keeps its keys in plaintext files (--keystore file) so the run never touches the keychain. The revocation picture's heartbeats carry real drand rounds. Identities, proof of work and timestamps differ on every run.

The tour is filmed by the same script, the same way, a step at a time with a real pointer. A second browser with its own virtual passkey plays the phone that scans the QR code. The tokens, the key event log and the terminals in it are that run's own. The voice is Orpheus, run locally.