People

Every entity in the directory gets a UUIDv7 at birth that never changes and is never reused. A login, a display name, an email and an organisational placement are all mutable attributes.

That is the one decision the rest of the model hangs off. LDAP's distinguished name is the identity, so moving a person between organisational units breaks every reference to them; the ACL syntax and the replication conflicts are downstream of it. Here a reference is a UUID and a name is a label.

cardinal user create alonfils -display "Arthur Lonfils" -email arthur@example.com -invite
cardinal show user alonfils
cardinal list user
cardinal list user -all      # includes disabled accounts

From Cardinal 0.7.0 the email is the administrator's to set: on Add person, with -email, or later from the account's page. It is where the enrollment link and the account's security notices go, so the person cannot change it from their own session; they can change their display name.

The entity types

user, group, host, service_account, application, device and role are the types the model allows. Four of them have commands and are in ordinary use; device and role exist in the type list and nothing creates one.

Core attributes are real columns: indexed and constrained. Anything organisation-specific lives in a JSONB attrs column governed by a schema registry in the database. There is no interface for editing that registry yet.

Renaming

Renaming is a console action (Directory → People, then the rename control on the person's page) and there is no CLI equivalent. The same dialog renames groups and hosts, and it says what each kind of rename changes downstream, because renaming a host means renaming it wherever the machine proves that name.

Nothing breaks, because nothing refers to a person by name.

Applications should not branch on names either. A group's name is a mutable attribute by design, so an application keying on the string "aura-admins" has coupled itself to something Cardinal intends to be renameable, and the day it is renamed, people lose access with no error anywhere. The identifiers are for branching; the names are for showing a human.

Disabling, and why there is no delete

cardinal user disable alonfils    # sessions and access tokens are revoked with it
cardinal user enable alonfils

Nothing here is a delete. History is kept either way, because the journal refers to entities by ID and a dangling reference would break audit queries, making the system less accountable in the name of tidiness.

The one operation that removes personal data is erasure, which is deliberately narrower and irreversible.

In the console

Directory → People lists everybody. A person's page shows their direct memberships with the period on each, how many passkeys they have registered (and warns when that is one), their outstanding invitation if any, and the control that disables the account.