Declarative Access

The Principle

Define identity in configuration, not in consoles. Users, groups, roles, memberships, and permissions are described in structured configuration files. These files declare the desired state, not the steps to achieve it. A new team member is not a sequence of actions. They are a declaration of who they are and what they should access.

Why Imperative Fails

The traditional model is imperative: open a console, click “create user,” select permissions from a dropdown, click save. This works for one user in one system. It fails beyond that. The admin interprets a ticket differently each time. Two admins produce different results from the same request. The action is ephemeral: once the clicks are done, the only record is a log entry buried in an admin console that few people read.

Identity providers and SSO have improved this picture. An Okta or Azure AD can federate authentication and push basic group memberships via SCIM. A ticketing system captures the approval chain. These tools solve real problems: single sign-on, centralized authentication, basic lifecycle events.

But they do not solve the problems this manifesto addresses. An identity provider knows which groups a person belongs to; it does not know whether those groups grant the right permissions in each downstream system. A ticketing system records that an approval happened; it does not record the blast radius of what was approved. SSO reduces the number of passwords; it does not reduce the number of permission models that must be managed. The gap between “federated authentication” and “declarative access” is the gap between knowing who someone is and knowing what they can do.

Declarative definitions address this remaining class of problems. The configuration is precise, reviewable, and produces the same result regardless of who applies it or when. Interpretation still exists: it lives in the mapping between abstract declarations and concrete system permissions. But it happens once, in a reviewed and versioned configuration, rather than every time an admin reads a ticket.

The problem sharpens with contractors and third parties. A contractor joining for a fixed-term engagement is provisioned through the same manual process as a full-time employee, except the person filing the ticket has less context on the contractor's actual scope and the person approving it has less visibility into what the role requires. The result is over-provisioned access for someone the organization knows less about, with a revocation date tracked by calendar reminder rather than by the system. Third-party service providers compound this: their access follows a separate workflow, managed by a different team, tracked in a different system. The organization cannot answer the question “what can our contractors and vendors access right now?” because the answer is distributed across as many workflows as there are external relationships.

Beyond Individual Systems

In a multi-platform environment, declarative identity means that a single set of configuration files describes a person's access across all the services they touch. The declaration is abstract: “this person is a senior engineer on the payments team”, and the concrete permissions in each downstream platform are derived from that abstraction. The person is defined once; the systems interpret that definition according to their own rules.

Mergers and acquisitions make heterogeneity structural. The acquired company arrives with its own identity model: different role definitions, different naming conventions, different assumptions about what constitutes a privileged action. Two organizations that defined access independently now share infrastructure, and their people carry incompatible access patterns into shared systems. The declarative model absorbs this variation rather than fighting it. The acquired company's roles are expressed as new definitions in the configuration, their people are assigned to those definitions, and reconciliation progressively aligns actual access with the unified model. The alternative — running two parallel access models indefinitely, or reconciling them through a one-time manual migration that misses half the edge cases — is the kind of ad-hoc process this manifesto argues against.

Upstream: People Come From Somewhere

The configuration repository is the authoritative record of access state, but it is not the origin of identity data. A person's name, manager, department, and employment status come from upstream systems: HR platforms, directories, employment databases. The declarative access model consumes these as inputs. When someone's employment ends in the HR system, the access system detects the change and triggers revocation. When someone transfers departments, the new team assignment flows through.

The repo owns what access a person has. The HR platform owns who the person is and whether they are still employed. The HR system is authoritative for employment state. The repository is authoritative for access state. An employment change in HR triggers a change in the repository; it does not bypass it.

Antipatterns

• Access is provisioned by clicking through admin consoles, not by editing configuration.
• Two admins interpret the same request and produce different results.
• The only record of an access change is a log entry buried in an admin console.
• No one can reproduce a person's access without opening each system individually.
• Contractors and third parties are provisioned through separate workflows with no unified view of their access.
• An acquired company's access model runs in parallel indefinitely with no reconciliation plan.