Auth for humans and agents — one primitive.
The identity primitive of the estate: one issuer for human sign-in and agent credentials — an SDK you install today, a discovery document a machine reads cold, and every seam between them stated in the open.
A builder shipping anything callable today serves people and machines at the same door. For the people, identity is a solved aisle: hosted sign-in, social providers, session cookies — pick a vendor. For the machines, the same vendors have nothing, so the builder reaches for the oldest hack in the stack: generate an API key in a dashboard, paste it into an environment variable, and let an autonomous agent walk around holding its principal's entire authority, forever, with no name of its own. Nothing in that key says who is calling, what it consented to, or when its authority should die. The half that authenticates humans is a commodity; the half that authenticates agents is nobody's product — and the builder who needs both is offered an identity practice to assemble: an authorization server to run, token storage to secure, middleware to write, key rotation to remember.
The tax lands hardest exactly where the estate's premise lives: on builders and businesses too small to staff a security function. And it lands first, because identity is the first call — nothing downstream can be metered, permissioned, or trusted until "who is calling?" has an answer. An agent that cannot prove who it is cannot be a customer. Authentication that only knows one species is half a primitive.
Three things in this estate are the substrate itself: the studio, the platform, and the runtime. This is deliberately not a fourth. And within identity there are two coordinates, not one: the estate's role table files identity → id.org.ai with status active — id.org.ai is the issuer, the authority that mints and signs. oauth.do is the primitive a builder installs to consume it: the SDK, the CLI, the middleware, the hosted login door. The issuer answers "who is this?"; this door is how a builder's product asks. One issuer, one primitive — the boundary this record keeps throughout.
In the estate's own registry the coordinate is exact: noun OAuth, verb authorize, type primitive, category primitives/security, priority P1, status implemented, price free. The seam with agents.do is a boundary rule, not an overlap: the runtime is where an agent lives and runs; this primitive is who the agent IS when it calls anything — the runtime hosts, the primitive attests.
One seam is worn on this slide rather than buried: the apex oauth.do
serves today, but the page it serves is the issuer's sign-in application
under the id.org.ai masthead — title, identity, and canonical URL all
the sibling's. The estate has case law for exactly this shape, and the
rule is candour: the apex's behavior is posted below as the live fact it
is, and the masthead seam is a pending claim with its gate, not a
footnote.
That is the whole human integration. The published package — MIT, on npm
today — documents five entry points on one install: the universal core
(oauth.do), Node with CLI helpers and OS-keychain token storage
(oauth.do/node), React components and hooks (oauth.do/react), Hono
middleware for Cloudflare Workers (oauth.do/hono), and session
utilities (oauth.do/session). The CLI ships in the same package:
npx oauth.do login · logout · whoami · token · status. Gating your own
doors is the same seam in reverse — requireAuth middleware with roles
and permissions, so every caller your product answers arrives with a
verified identity instead of a pasted secret.
For the machine species, the grammar is already posted where a machine
would look — the discovery document this domain serves cold: the device
grant for headless environments (a CLI or agent displays a code, a
human approves once, the machine holds its own token), client
credentials for service callers, PKCE-only public clients, and an
agent_auth extension block — identity, claim, and events endpoints
with the id-jag subject-token type. Stated at its actual state: that
block is the issuer's posted metadata, and the repo carries the OAuth 2.1
server implementation behind it (Workers plus Durable Object storage,
with WorkOS named as the upstream in its own deployment guide) — but no
end-to-end agent flow is claimed here until one runs cold in the docs.
The discovery document advertises the full agent grammar, including a registration endpoint. This record claims the metadata as served — it is quoted in evidence on the proof slide — and does not claim a verified round-trip through it until a runnable example posts. The grammar is posted; the proof of the loop is behind this gate.
import { auth } from 'oauth.do'
// one call — browser, Workers, or Node
const { user, token } = await auth()
Concreteness over adjectives: each door below was checked cold on 2026-07-31 and carries its own state and its own evidence URL — never one URL evidencing several domains. Serving is a liveness fact, not a tenancy claim: nothing here asserts external tenancy, seat counts, or a usage roll. Those publish behind their own gates.
oauth.do serves. The apex answers 200 with the estate identity rail's
sign-in door — "Humans. Agents. Identity. Simple, secure sign-in for
humans and AI agents," with GitHub, Google, Microsoft, Apple, and
LinkedIn sign-in — rendered under the issuer id.org.ai's masthead. That
masthead seam is this deck's first amber, one slide down.
The domain's standards door answers a machine cold: GET /.well-known/oauth-authorization-server returns a complete RFC 8414
authorization-server metadata document — issuer https://id.org.ai, four
grant types including the device grant and client_credentials, PKCE S256,
and the agent_auth extension block — no login, no signup.
The package is published: the npm registry serves the oauth.do package
record cold, dist-tag latest at 0.3.3 — a 0.x version, worn as the
pre-1.0 fact it is.
The dedicated public repo serves: SDK entry points, CLI, React and Hono integrations, and the OAuth 2.1 authorization-server implementation (Workers + Durable Object), readable by anyone today.
The hosted login door routes: login.oauth.do answers 307 into the
issuer's managed login flow at api.id.org.ai — a routing fact, stated
as exactly that.
id.org.ai serves — the issuer's own door, the coordinate the estate's
role table files as identity, status active. Serving is a liveness fact,
not a tenancy claim.
Three ambers, worn in the open — the agent-flow proof, already stated at its gate on the contract slide, and the two below — each the exact distance between what serves and what this door intends to be. (The figures gate on the economics slide is the estate's standing stack#1 §A5 disclosure rule, carried by every record in the portfolio — an estate gate, not a fourth product amber.)
The apex serves today — under the sibling issuer's masthead. The page a
builder resolves at oauth.do is the id.org.ai sign-in application:
right rail, wrong nameplate for a door whose buyer arrives looking for an
SDK. The estate's one-brand-one-surface rule says this flips when the
apex serves oauth.do's own developer front door — quickstart, entry
points, the discovery document linked — or when the shared masthead is
ratified. Queued in the program doc either way.
The standards door answers a machine cold, but the estate's own machine
grammar is not yet here: oauth.do/api returns a not-found error
envelope, oauth.do/llms.txt is a 404, and the gateway's apis.do/oauth
path answers "OAuth endpoint not found" rather than a service record. A
machine that resolves this primitive through the estate's own catalog
conventions finds the doors dark. The claim flips when the catalog
serves.
Primary motion is B2D: the buyer is a developer who evaluates at the
npm page, the public repo, and the discovery document, and converts at
the first successful await auth() — no sales motion, no demo call, no
procurement. The evaluation surface is the product surface, which is why
the apex-masthead amber is this deck's most important gate. Secondary is
B2A, and for this door the machine motion is unusually literal: the
agent is not just a buyer of this primitive, it is the SUBJECT — the
device grant, client_credentials, and the agent_auth block are how a
machine gets an identity at all. The first leg of that motion already
serves, because the discovery document answers a machine cold with the
full grammar. Everything past that leg — registration round-trips,
id-jag assertions in production — gates on the contract slide's amber,
exactly as the sibling records state for theirs.
Layer-1 economics at the entry point: the primitive is free by the registry's own coordinate, because identity is where every tenancy begins — its economics are distribution economics, and the value it routes is metered downstream at the doors it unlocks.
Free is not a promotion here; it is the coordinate. The registry files this door's price as free and the package is MIT, because the identity primitive's job is to make every other door callable: each builder who answers "who is calling?" through this seam is a tenancy the estate's metered doors — compute, data, models, payments — can serve on their own posted terms. The cost side is already carried by running the estate's own stack, which authenticates here by construction. And there is no statutory floor anywhere in this function: nothing in verifying a caller reserves a step for a statutory person, so the implementation mix migrates all the way to Code.
Sign-in counts, token volumes, tenant counts, and the internal-versus-external split are gated. Each figure publishes with its window and base or it does not publish.
humans sign in through a hosted door; machines authenticate with the device grant, client_credentials, and the agent_auth grammar — one identity spine instead of a sign-in vendor plus a key spreadsheet
every door the estate launches asks "who is calling?" through this seam over the estate’s own issuer — demand generated by the portfolio itself, structural before commercial; the usage roll publishes behind its stack#1 §A5 gate or not at all
the agent grammar is served RFC 8414 metadata today — device grant, PKCE, client_credentials, id-jag subject tokens — not a roadmap slide; a machine can read the contract cold before any sales motion exists
SDK, CLI, React, Workers middleware, keychain storage, and hosted login in a single package — replacing it means reassembling an identity practice, which is the exact burden the builder came here to delete
The claim ledger lives on the "What serves today" and seams slides — one posted chip per live door, one amber per gate, each stated once. This slide is the evidence in kind: what a machine actually receives when it resolves this primitive, retrieved cold on 2026-07-31 with no login and no signup.
The standards door. GET https://oauth.do/.well-known/oauth-authorization-server returns this
RFC 8414 document (abridged — scopes and response types omitted):
{
"issuer": "https://id.org.ai",
"authorization_endpoint": "https://id.org.ai/oauth/authorize",
"token_endpoint": "https://id.org.ai/oauth/token",
"registration_endpoint": "https://id.org.ai/oauth/register",
"device_authorization_endpoint": "https://id.org.ai/oauth/device",
"grant_types_supported": [
"authorization_code",
"refresh_token",
"client_credentials",
"urn:ietf:params:oauth:grant-type:device_code"
],
"code_challenge_methods_supported": ["S256"],
"agent_auth": {
"identity_endpoint": "https://id.org.ai/agent/identity",
"claim_endpoint": "https://id.org.ai/api/claim",
"events_endpoint": "https://id.org.ai/agent/events",
"subject_token_types_supported": [
"urn:ietf:params:oauth:token-type:id-jag"
]
}
}
Every claim this deck makes about the machine grammar is a line in that
document: the issuer boundary (issuer is id.org.ai — the primitive is
not the issuer), the device grant for headless machines, PKCE-only
public clients, and the agent_auth block with the id-jag subject-token
type. The contract slide's amber is visible here too: registration_endpoint
is advertised, and this record claims the advertisement, not a verified
round-trip.
The hosted login door. curl -s -o /dev/null -w '%{http_code} %{redirect_url}' https://login.oauth.do/ returns:
307 https://api.id.org.ai/user_management/initiate_login?…
A routing fact: the login subdomain hands the browser to the issuer's
managed login flow. The doors that do NOT yet serve are stated with the
same precision on the seams slide — oauth.do/api and apis.do/oauth
answer error envelopes, llms.txt a 404 — shown there as the deck's
machine-catalog amber rather than rounded away here.
The package is oauth.do — npm install oauth.do runs today, and the
discovery document at oauth.do/.well-known/oauth-authorization-server
answers a machine cold.
If this was forwarded to you: oauth.do is the identity primitive of the startups.studio estate's infrastructure layer — the WHO under every other door, for human and agent callers alike. It is deliberately not one of the estate's three substrate properties, and it is not the issuer either: the issuer is id.org.ai, and this record keeps that boundary explicitly. What is live is posted with a URL checked cold — the apex, the RFC 8414 discovery document, the npm package, the public repo, the login route, the issuer's door — and what is not is pending with the gate that flips it, including the three ambers it wears openly: the apex serving under the sibling issuer's masthead, the missing estate-convention machine catalog, and the agent flow not yet demonstrated end-to-end. Judge it by what is posted, and by how plainly it labels what is not.