Cursor identity and authorization

Cursors needs sign-in without turning a social account, hostname, cookie, or bearer token into a Self. The proposed Cursor Authorization Protocol is a signed mailbox challenge with an OAuth-compatible boundary.

The cockpit now implements the first inner layer: a local encrypted identity vault can create and unlock an Ed25519 mailbox key without Cloudflare. Remote mailbox authorization remains the protocol design below; local key existence is not remote admission.

This is a protocol design, not a deployed authentication claim.

Human model

1. A site asks to speak to a named mailbox and displays the exact attenuated rights it wants.
2. The authorization service sends an encrypted one-time challenge to that mailbox.
3. A local key agent or enrolled device shows the request and signs the nonce, origin, redirect target, requested rights, expiry, and PKCE challenge.
4. The service verifies the pinned mailbox key and returns a one-time authorization code.
5. The client exchanges the code plus PKCE verifier for a short-lived, proof-of-possession-bound session.

There is no reusable password and no long-lived bearer credential in a cursor. The Self is the verified key lineage; the mailbox is a delivery address; the browser session is a replaceable projection.

OAuth and OIDC compatibility

Compatibility can live at the boundary:

• /authorize accepts client_id, exact redirect_uri, state, requested scope, and a PKCE challenge;
• /token consumes a one-time code and verifier;
• access tokens are short-lived and bound to the client's signing key with proof of possession;
• an optional ID token uses a stable key thumbprint or signed Self identifier as sub;
• discovery metadata lets conventional clients understand the endpoints.

Internally, requested scopes compile to attenuated Cursors capability grants. OAuth compatibility does not make an OAuth provider the identity root and does not allow bearer tokens to enter canonical cursor records.

Mailbox and device flows

The same challenge can arrive through a paired device, QR transfer, local agent, encrypted email adapter, Caravan mailbox, or delay-tolerant store. Transport changes do not alter the signed challenge. A device code is only a rendezvous reference; approval still requires a local signature over the exact request.

Recovery and rotation

Recovery is more important than login polish. A production design needs:

• offline recovery keys or a threshold of nominated recovery identities;
• signed successor statements for key rotation;
• explicit device enrollment and removal records;
• short expiries, replay caches, origin binding, and redirect allowlists;
• a visible revocation and recovery drill before public sign-in launches.

WebAuthn or passkeys may protect a device key, but they are an adapter, not the universal Cursors identity model.