technical passkeys, delegation, AT Protocol, threat model

Identity: a passkey and an AT Protocol account

Sign-up does two things. It registers a passkey by WebAuthn with residentKey: required and ES256 as the only accepted algorithm, so the passkey is a P-256 key held by the person's device. Attestation is none and user verification preferred: attest asks the device nothing about itself and accepts any authenticator, whether a phone, a Linux desktop, a password manager or a hardware key. (WebAuthn attestation, the authenticator vouching for its own make, is unrelated to attest's records, which are people vouching for URLs and keys.) And it creates an AT Protocol account on our data server (PDS): a did:plc in the public PLC directory, a repository, and a handle <name>.attest.monster bound to the DID by a DNS TXT record at _atproto.<handle>. The account's password is a random server-side secret nobody sees; the passkey is the person's key. We store the credential id, the passkey's public key, its signature counter, the handle and the DID. There is no email and no password the person uses.

The passkey's public key is also expressed as a did:key (multicodec prefix for P-256, 0x1200, then the 33-byte compressed point, base58btc with a z prefix; these start did:key:zDna). The account's identity is the did:plc; the passkey is what controls the account's delegations. A passkey cannot itself be the PLC rotation key, because AT Protocol rotation keys sign raw bytes and WebAuthn signs a challenge structure, so the rotation key for accounts made here is held by the service and backed up off the server.

Delegation to a device key

WebAuthn signatures are bound to the relying party's origin and each one prompts the user. A site on another origin cannot ask your passkey to sign, and a prompt per upvote is unusable. So the passkey signs a delegation instead.

delegation {v:2, type:"delegation", root, device, devKey:{x,y}, originHash, from, until}
originHash = sha256(canonical({origin, salt}))   // origin and a 16-byte salt travel beside it, never inside it

• device is a P-256 key the integrating page generated with WebCrypto, private half non-extractable, stored in that origin's IndexedDB. It never leaves the browser and never reaches us in private form. devKey is its public JWK.
• originHash commits to the bare origin of the page that will use the delegation, without naming it. The site's session holds the origin and the salt, so the site can prove the binding; nobody else can tell which site it was. We keep the origin privately, to refuse a record whose socket origin differs from it (a request with no origin is refused) and to show the person their own sign-ins. A delegation enters the public log only when something signed with it is published. Before 2026-10-02 (v1) the origin was in clear; those entries naming other sites were deleted.
• from must be within ten minutes of server time; until is at most 90 days later. The login page issues 30.

The delegation's id is the SHA-256 of its canonical JSON. That id, as bytes, is the WebAuthn challenge; the passkey's assertion over it is the signature on the delegation. Sign-in therefore is the act of delegating, and a returning user sees one prompt. The assertion (authenticatorData, clientDataJSON, signature) is stored with the delegation and appended to the log, so anyone with the root's public key can verify the delegation later, offline. The signature counter is updated and monotonic.

On a page of another origin, the login page runs in a popup on our origin (so the passkey works), receives the page's device DID and public JWK in the query string, and posts the finished session back with postMessage to the origin in the delegation. On our own origin it is a redirect.

Agents

An agent is a program acting for a person. It holds its own P-256 key, and the person's passkey signs a permission for it, as it signs a delegation for a browser:

agent {v:1, type:"agent", root, agent (did:key), agentKey:{x,y}, name, purpose,
       permissions:["repo:monster.attest.comment?action=create&action=delete", …], limits:{perDay}, from, until}

• permissions are AT Protocol permission strings (atproto.com/specs/permission), limited to attest's own record types. A write outside them is refused; so is a write past perDay in the last 24 hours, or after until (at most 90 days) or a revocation.
• Public at once. Unlike a browser sign-in, an agent permission is published when signed: the log carries it with the passkey's assertion, and /agent/<id> serves it. Anyone holding something the agent signed can see whom it acts for and within what bounds.
• No trust of its own. Records go into the person's repository with by = the person; a vote or vouch is one per subject per repository, so any number of agents add nothing one does not. Comments are shown "via" the agent. Agents cannot make admin or owner requests, and cannot delegate further.
• The hand-off follows the user-claimed flow of WorkOS's auth.md: the agent posts its public key and request, gets a code and a link; the person opens the link on attest, checks the code, may narrow the request, and approves with their passkey; the agent polls for the result. Pending requests live 15 minutes, in memory, unpublished. Where auth.md ends in a bearer token, this ends in a signed public permission naming the agent's own key, so each record remains attributable.
• Transport. Agents use plain HTTP and JSON (/agent/request, /agent/poll/:token, /agent/attest, /agent/retract), since they are programs, not browsers; the browser pages keep the socket. The agent endpoints accept only agent permissions, so a site sign-in cannot be replayed there without its origin.
• Threats. A stolen agent key can write within its permission until revoked or expired; keep permissions narrow and short. The permission cannot be widened without a new passkey signature. Whether an agent is "really" an AI is not something attest tries to settle; what it records is who answers for it. The closest general form is UCAN, capabilities delegated key to key; attest's permission is a one-step version of that, with no further delegation.

Records in repositories

A record is an AT Protocol record in the author's repository, in one of our lexicons, monster.attest.{vote, comment, statement, vouch, claim, verification, bookmark}, published at _lexicon.attest.monster. Each carries the author's inline signature in the shared app.certified.signature.defs#inline shape, as in badge.blue and Hypercerts: the device key signs the 36-byte CIDv1 (DAG-CBOR, SHA-256) of the record with its signatures removed and a $sig object {$type, key, repository} inserted. ECDSA P-256, raw r||s, low-S. Because the repository DID is inside what is signed, a signature cannot be replayed into another repository.

The client builds and signs the record; the service checks the signature against the delegated device key and the repository DID, checks the delegation is live and was issued for the calling origin, validates the record against the lexicon, and writes it into the repository through the PDS. Votes, vouches, claims and bookmarks use a record key derived from the subject, so there is one per author per subject; comments and statements use time-ordered keys. Retraction deletes the record, authorised by a device-key signature over {type:"retract", uri, at}.

The service's index (SQLite) is derived from the repositories. It follows the PDS's subscribeRepos firehose: a record in our collections written by any client is verified against its repository and indexed, an unsigned one is ignored, a deletion retracts, and an account's deletion or deactivation removes its records from all counts. Delegations, revocations and passkey changes, which are not repository records, are kept in the index's own log with their passkey assertions.

Identities proven on Bluesky are linked, and the trust they have already declared on AT Protocol is imported as edges: Tangled vouches and denouncements (sh.tangled.graph.vouch, subject in the record key), Tangled follows and Bluesky follows. Each is kept as its own kind so a scorer can weigh them differently. Imports refresh every six hours.

What we take from AT Protocol, and where we differ

Other borrowings: the NIP-73 identifier grammar for subjects; SIWE's idea that a login is a signed, origin-bound, time-stamped message; Farcaster's per-app signer keys under one root.

Threat model, as it stands

Root actions

Sign-in is one instance of a general shape: the passkey signs an action by signing a WebAuthn assertion whose challenge is the action's SHA-256. The others are revoke (a delegation), add-key and remove-key (passkeys on the account). Each is kept in the index's log with its assertion, so account history can be replayed and checked. The service offers only the account's own passkeys in the browser prompt, and never the one being removed.

Proof of control and the service key

A claim record says a key controls a handle or URL. The token attest-proof:<claim cid> goes where only the controller can put it: the page itself or /.well-known/attest.txt for a website, a TXT record at _attest.<domain>, a public gist, a Bluesky bio. The service fetches, and if it finds the token it writes a verification record into its own repository (attest.attest.monster, DID at /service), signed inline by its own P-256 key, with the evidence URL. Any other account may verify a claim by writing its own verification; each counts as far as its author is trusted. A verified Bluesky claim also links that identity for the graph read-in above.

Practices borrowed from neighbours, and what is still to adopt

Canonical JSON

Used only for delegations, agent permissions, revocations and retraction authorisations, which are not repository records: object keys sorted at every level, arrays in order, undefined dropped, no whitespace. Repository records are hashed as DAG-CBOR, as AT Protocol specifies.

Source: github.com/orbitalfoundation/attest. Reading behind these choices is in the repository's reference/ and devlog/.