Shared infrastructure for identity, authentication, authorization, and access control.
Identity provides reusable primitives and contracts for establishing who or what is interacting with a system and what that identity is allowed to do.
Rather than implementing identity and authorization independently inside every application, this repository centralizes shared identity concepts behind explicit boundaries and provider-agnostic interfaces.
Its purpose is to make identity a reusable platform capability.
Identity concerns appear in nearly every non-trivial system.
Users need identities.
Services need identities.
Agents need identities.
Sessions need to be represented.
Permissions need to be evaluated.
Resources need access policies.
External identity providers need consistent integration boundaries.
When these concerns are implemented independently across applications, authorization logic becomes fragmented and difficult to reason about.
Identity exists to provide a common foundation.
Identity may include:
- Identity models
- Authentication contracts
- Authorization primitives
- Roles
- Permissions
- Policies
- Claims
- Sessions
- Service identities
- Agent identities
- Access-control evaluation
- Provider adapters
- Identity resolution
- Principal representation
- Resource ownership
- Authorization context
- Audit context
```text identity/ ├── adapters/ ├── auth/ ├── authorization/ ├── claims/ ├── policies/ ├── principals/ ├── roles/ ├── sessions/ └── utils/ ```
The structure will evolve as concrete identity requirements emerge across consuming systems.
Identity should distinguish between authentication and authorization.
```text Identity │ ▼ Authentication │ ▼ Principal │ ▼ Claims │ ▼ Authorization │ ▼ Policy Evaluation │ ▼ Decision ```
Authentication establishes identity.
Authorization determines what that identity may do.
These concerns should remain related but independently understandable.
A principal represents an authenticated actor within a system.
A principal may represent:
- A user
- A service
- An application
- An API client
- An AI agent
- An automated process
Consumers should be able to reason about authorization without depending on how the principal originally authenticated.
Authorization should be explicit and centralized around well-defined decisions.
Examples include:
```text can(user, "read", document)
can(service, "publish", event)
can(agent, "execute", capability) ```
The exact authorization model may evolve as requirements become clearer.
The important constraint is that access decisions should not become scattered application-specific conditionals.
Identity should not require applications to depend directly on a particular authentication provider.
Provider-specific behavior belongs behind adapters.
```text Application │ ▼ Identity �[118;1:3u │ ├── Provider Adapter ├── Provider Adapter └── Provider Adapter ```
Applications consume stable identity contracts while authentication providers remain replaceable where practical.
Identity is security-sensitive infrastructure.
The repository should therefore prefer established security standards and proven implementations over custom cryptographic or authentication mechanisms.
Identity should compose trusted primitives rather than reinvent them.
In particular:
- Do not invent cryptographic protocols.
- Do not implement custom password hashing.
- Do not create proprietary authentication protocols.
- Validate external identity data at trust boundaries.
- Keep authorization decisions explicit.
- Prefer least-privilege access.
- Make security-sensitive decisions auditable.
The repository owns integration and policy architecture, not cryptographic novelty.
Identity owns shared identity and access-control abstractions.
It does not own every system that interacts with identity.
For example:
- Applications authenticate users through Identity contracts.
- Agent Network may represent agents as principals.
- Trust Platform may consume identity context when evaluating actions.
- Event Platform may attach actor identity to events.
- Observability may correlate operations with principals.
- Data Platform may use authorization decisions to protect connected resources.
Identity provides the common language those systems use to reason about actors and access.
Identity intentionally does not contain:
- Application-specific user interfaces
- Application-specific onboarding
- Business-domain user profiles
- Custom cryptographic algorithms
- A proprietary OAuth or OpenID implementation
- General Trust & Safety policy
- Application routing
- Deployment infrastructure
Those concerns belong in applications, specialized platforms, or established external implementations.
Identity is foundational infrastructure within the broader ecosystem.
It can integrate with:
- Agent Network — Agent and service identities
- Event Platform — Actor and authorization context in events
- Trust Platform — Identity-aware trust and policy evaluation
- Data Platform — Access control for connected data
- Search — Access-aware retrieval
- Observability — Identity-aware diagnostics and audit context
- Testkit — Identity fixtures and authorization test utilities
- Bootstrapper — Identity integration during project scaffolding
Applications consume Identity without duplicating authorization architecture.
The long-term goal is to provide a consistent identity layer across applications, services, tools, and autonomous agents.
A principal should be representable consistently regardless of whether it originated from a browser session, API token, service credential, external identity provider, or agent runtime.
Authorization should remain understandable as the ecosystem grows.
Identity should provide shared semantics without becoming a monolithic identity provider.
Identity is in early development.
Its architecture will grow from concrete authentication and authorization requirements across consuming systems rather than speculative abstraction.
Licensed under the MIT License.