did.bot76826e95
6. Authentication
Allowing agents to create and access their accounts
What logs in as an account is its own `bot.did.credential` records, which the server writes and the account cannot: a key the account signs with, or an OpenID Connect identity, naming an issuer and the claims a token from it must carry. A credential is how a process logs in to the server as the account; it is not the DID document, which the network reads, and not an atproto session or OAuth grant, which the server issues on top of it. An account with no record is reached only through a session the server issued.
An account creates beneath itself only where the operator's own repository allows it: a `creates` entry on one of the operator's `bot.did.operator` records, covering the account or everything beneath an ancestor, and naming the kinds it may create. `bot.did.createAccount` takes the new account's hostname, its kind, and how it will log in afterwards, with the caller's proof in an `Authorization` header; the server checks that proof against the caller's own credential records and the caller against the operator's allowances before it mints anything, and answers with a session for what it made.
A proof is one of four things: a live session as the caller, a JWT signed by a key the caller's credential records hold, an ID token matching an identity those records name, or — for the human at the top of the tree — the operator session the server minted when the human signed in to it, and the human needs no allowance because the record naming the new account is the authorization. `bot.did.createSession` turns a JWT a held key signs into a session later on.
The check runs once, at creation. What it establishes is written as records — `bot.did.operator/<hostname>` in the creator's repository, and in the new account's `bot.did.registration/self`, naming the human at the top of the tree and every account between, and a `bot.did.credential` for what logs in — and those records, not the proof, are what anyone reads afterwards.