Files
Ekklesia/packages/contracts/src/identity.ts
ekklesiaandClaude Opus 5 80189c8ae2
CI / verify (pull_request) Successful in 40s
CI / infrastructure-smoke (pull_request) Successful in 21s
CI / migration-smoke (pull_request) Successful in 1m22s
feat: give display devices their own paired identity
ADR 0033 gave Ekklesia a display host and ADR 0034 gave it a login page.
Together, the only way to light a television in a foyer was to sign a
human being into it and leave that session running on a screen anyone can
walk up to: a person's credentials on a wall, a person's session as the
thing signage depends on, and the display going dark when they are
revoked or their session simply expires.

A screen is not a person. Ekklesia now recognizes three principal classes
— anonymous, authenticated human, and managed device — and a device is a
first-class principal with its own credential and its own explicit
permissions. It has no email, no password, and no row in the identity
tables, and it satisfies the `authenticated` baseline never, so every
route that settles for "somebody is signed in" stays closed to it.

Device permissions live in their own table because
ekklesia_core_grant.user_id is a non-null foreign key into the user table
and making it polymorphic would rewrite the platform's central
authorization record to serve one narrow case. That is a schema decision,
not a second decision point: the evaluator gained one branch, so a device
is allowed or denied by the same function, with the same deny-by-default,
as anyone else — with no owner path it could reach and no baseline that
stands in for a grant.

The six-digit code is not the credential. It is printed across a screen in
a public hallway, so it is treated as public: it identifies a request to
an administrator and is worth nothing alone. Collecting the credential
also requires a 256-bit claim secret held only in the requesting browser's
HttpOnly cookie, and approving requires the restricted core.devices.manage
permission. Without that split, reading a code off a wall would hand over
the screen's identity.

The permission a pairing asks for is read from the module's validated
display declaration, never from the request, so a browser cannot ask to be
granted core.devices.manage or another module's permission. Approval
grants exactly that one permission.

Credentials are stored only as SHA-256; the raw value exists in the
Set-Cookie that issues it and the device's own cookie jar, and is never
logged, returned in JSON, or placed in a URL. The cookie is HttpOnly, so
the module display code running in that same page cannot read it.
Revocation is a server-side column checked on every principal resolution,
and re-pairing mints a new identity so an old credential can never come
back. State transitions are conditional updates, so one code cannot be
approved twice or claimed into two credentials under a race.

/api/v1/principal still reports a device as anonymous: it is what the
Dashboard uses to decide whether a person is signed in. Displays read
their viewer from the descriptor instead, which already performed the
authorization — so displays are descriptor-first while the Dashboard stays
principal-first, and neither infers an identity by elimination.

Proven end to end against real PostgreSQL and real HTTP: an unpaired
screen shows a code, an owner approves it, the device opens the display
descriptor and a realtime stream, and revocation closes both while the
device still holds its cookie. An already-open SSE stream is bounded by
realtime's existing five-minute reconnect rather than closed instantly,
and that bound is documented rather than called immediate.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-08-23 23:41:03 -05:00

119 lines
4.4 KiB
TypeScript

import { z } from "zod";
/**
* Opaque at the type level via Zod's nominal `.brand()`: a plain `string` is not assignable to
* `EkklesiaUserId` without passing through `parseEkklesiaUserId`/`safeParseEkklesiaUserId`. The
* brand exists only in the type system — it adds no runtime tag, wrapper, or field, so a value
* still serializes (JSON.stringify, string concatenation, equality) as a plain opaque string.
* Ekklesia does not assume any particular format (in particular, not UUID): Phase 4A's identity
* schema stores Better Auth's default application-generated id, an opaque base62-ish string, not
* a database-generated UUID. Only the constraints Ekklesia itself owns are validated: non-empty
* after trimming, and a generous upper bound against unreasonably large values.
*/
export const ekklesiaUserIdSchema = z.string().trim().min(1).max(128).brand<"EkklesiaUserId">();
export type EkklesiaUserId = z.infer<typeof ekklesiaUserIdSchema>;
export function parseEkklesiaUserId(input: unknown): EkklesiaUserId {
return ekklesiaUserIdSchema.parse(input);
}
export function safeParseEkklesiaUserId(input: unknown): z.ZodSafeParseResult<EkklesiaUserId> {
return ekklesiaUserIdSchema.safeParse(input);
}
/**
* A managed display device: a TV, signage player, or confidence monitor that the platform paired
* and can revoke.
*
* It is deliberately **not** a user. A device has no email, no password, no session that a person
* signs into, and no row in the user table — representing one as a fake user would make every
* "is this a person?" question in the platform unanswerable, and would quietly hand a screen in a
* hallway whatever a signed-in human is allowed to do.
*
* A device principal carries only the permissions explicitly granted to that device. It satisfies
* no `authenticated` baseline: "unattended screen in the foyer" is not "a person is signed in",
* and every route gated only by "someone is logged in" would otherwise open to it (ADR 0036).
*/
export const ekklesiaDeviceIdSchema = z
.string()
.regex(/^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/u)
.brand<"EkklesiaDeviceId">();
export type EkklesiaDeviceId = z.infer<typeof ekklesiaDeviceIdSchema>;
export function parseEkklesiaDeviceId(input: unknown): EkklesiaDeviceId {
return ekklesiaDeviceIdSchema.parse(input);
}
export function safeParseEkklesiaDeviceId(input: unknown): z.ZodSafeParseResult<EkklesiaDeviceId> {
return ekklesiaDeviceIdSchema.safeParse(input);
}
export interface EkklesiaAnonymousPrincipal {
readonly kind: "anonymous";
}
export interface EkklesiaAuthenticatedPrincipal {
readonly kind: "authenticated";
readonly userId: EkklesiaUserId;
}
export interface EkklesiaDevicePrincipal {
readonly kind: "device";
readonly deviceId: EkklesiaDeviceId;
}
/**
* The three principal classes Ekklesia recognizes. They are deliberately a closed union rather than
* "authenticated or not": code that means *a person* must be able to say so, and code that merely
* needs *some* caller must not accidentally accept a device.
*/
export type EkklesiaPrincipal =
| EkklesiaAnonymousPrincipal
| EkklesiaAuthenticatedPrincipal
| EkklesiaDevicePrincipal;
export const ANONYMOUS_PRINCIPAL: EkklesiaAnonymousPrincipal = Object.freeze({
kind: "anonymous",
});
export function createAuthenticatedPrincipal(userId: unknown): EkklesiaAuthenticatedPrincipal {
return Object.freeze({
kind: "authenticated",
userId: parseEkklesiaUserId(userId),
});
}
export function createDevicePrincipal(deviceId: unknown): EkklesiaDevicePrincipal {
return Object.freeze({
deviceId: parseEkklesiaDeviceId(deviceId),
kind: "device",
});
}
export function isAnonymousPrincipal(
principal: EkklesiaPrincipal,
): principal is EkklesiaAnonymousPrincipal {
return principal.kind === "anonymous";
}
/**
* Whether this principal is a signed-in **person**.
*
* A device principal deliberately returns `false`. Every existing caller of this predicate means
* "a human is authenticated here" — the Dashboard shell, the `authenticated` permission baseline,
* the grants API — and each of them would be wrong about a screen on a wall.
*/
export function isAuthenticatedPrincipal(
principal: EkklesiaPrincipal,
): principal is EkklesiaAuthenticatedPrincipal {
return principal.kind === "authenticated";
}
export function isDevicePrincipal(
principal: EkklesiaPrincipal,
): principal is EkklesiaDevicePrincipal {
return principal.kind === "device";
}