Service identities

Non-human callers — CLIs, cron jobs, internal scripts, intranet agents — register an Ed25519 public key here and authenticate at /token with a signed client assertion. One key per caller; one issued token per (caller, audience) pair.

M1 stub. Service-identity registration ships in M6. The form below shows the data we'll capture; submitting does nothing yet.

Registered services M6

No service identities yet. M6 ships the identity_service_keys table and a provisioning CLI (scripts/id-admin.ts) that calls into this surface.

example: prx-cron
UUID 00000000-0000-0000-0000-000000000000 · kid cron-2026a · scopes jobs:run

Sample
example: prx-deploy-bot
UUID 00000000-0000-0000-0000-000000000001 · kid deploy-2026a · scopes deploy:read deploy:write

Sample

Register new service identity M6

How service tokens work

SysOps generates an Ed25519 keypair on the box that will hold it; private key stays put.
The public key + scopes get registered here, returning a kid.
The caller signs a short JWT with its private key (header includes the kid) and POSTs it to /token with grant_type=client_credentials and client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer.
Identity verifies the assertion against the registered public key, then issues an audience-scoped identity token (~5-min TTL).