coulomb/identity-canon
Archived
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Seeded research project with INTENT.md, ResearchProposal.md and initial work.

Browse Source
This commit is contained in:
Bernd Worsch
2026-06-04 12:12:07 +02:00
parent c190c62cd5
commit 8a1482098b
28 changed files with 2621 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

168
INTENT.md Normal file
View File

@@ -0,0 +1,168 @@
# INTENT.md
## Purpose
`identity-canon` exists to research, clarify, and define a canonical terminology and conceptual data model for identity, user, organization, community, and relationship management across multi-tenant, multi-vendor, multi-community systems.
The project is intentionally focused on the **research and terminology layer**. It does not implement user management, identity provisioning, authentication, authorization, or UI workflows directly. Instead, it provides the conceptual foundation that later implementation projects can rely on.
## Core Intent
The core intent is to develop a clear, orthogonal vocabulary and canonical model for describing:
* natural persons, users, accounts, identities, personas, and profiles
* organizations, enterprises, sub-organizations, vendors, tenants, customers, and legal entities
* communities, families, households, teams, spontaneous groups, and social graphs
* actors, agents, bots, service accounts, and delegated representatives
* memberships, affiliations, followers, ownership, representation, delegation, and trust relationships
* weak and strong synonymity between identities, accounts, identifiers, and real-world actors
* the distinction between social, legal, operational, and authorization-relevant relationships
The project should help avoid the common collapse of overloaded terms such as `user`, `group`, `role`, `tenant`, `organization`, `account`, and `identity`.
## Strategic Role
`identity-canon` is a reference project for future identity-related systems and implementation repositories.
It should provide:
1. a researched corpus of relevant standards, concepts, and terminology;
2. a canonical vocabulary suitable for humans and agents;
3. a conceptual model for user, organization, community, and identity management;
4. a basis for later schemas, APIs, CLI tools, UI workflows, and adapter implementations;
5. a shared language for connecting IAM, social graph, enterprise directory, community, family, and authorization concepts.
The repository should serve as a stable conceptual anchor before implementation-specific decisions are made.
## Intended Users
The primary users of this repository are:
* system architects designing multi-tenant identity and user-management systems;
* developers implementing user, organization, tenant, and community management components;
* security and IAM engineers integrating systems such as Keycloak, Keycape, LLDAP, Authelia, privacyIDEA, OpenBao, SCIM, OIDC, SAML, LDAP, OpenFGA, Cedar, or related tools;
* product designers creating CLI and UI workflows for managing users, organizations, communities, and relationships;
* AI agents that need a precise terminology reference when generating schemas, documentation, workflows, or implementation plans.
## Scope
`identity-canon` covers research, terminology, and conceptual modeling.
In scope:
* literature and standards research;
* terminology analysis;
* canonical concept definitions;
* comparison of overlapping terms across IAM, directory services, social graphs, enterprise systems, and authorization models;
* conceptual diagrams and model descriptions;
* model constraints and design principles;
* synonymity and entity-resolution concepts;
* scope, tenant, organization, community, family, and group distinctions;
* relationship semantics such as membership, affiliation, representation, delegation, following, ownership, and trust;
* recommendations for future implementation repositories.
Out of scope:
* implementation code;
* production APIs;
* database migrations;
* UI components;
* CLI commands;
* adapter implementations;
* direct integration with Keycloak, LDAP, SCIM, OIDC, SAML, OpenFGA, or other systems;
* operational identity lifecycle tooling.
Implementation repositories may later consume the results of `identity-canon`, but this repository remains implementation-neutral.
## Design Principles
### 1. Do not start with “user”
The term `user` is overloaded. The canonical model should avoid using `user` as the root concept. Instead, it should distinguish actors, natural persons, accounts, identities, profiles, personas, credentials, and principals.
### 2. Separate social, legal, operational, and authorization semantics
An organization may be a legal entity, a tenant, a community, a billing customer, an employer, a vendor, or an authorization scope — but these meanings must not be collapsed into one concept.
### 3. Model relationships explicitly
Membership, affiliation, following, ownership, representation, delegation, administration, and trust should be modeled as distinct relationship types, not hidden inside groups or roles.
### 4. Treat synonymity as an assertion, not a destructive merge
Weak and strong synonymity should be represented as scoped, evidenced assertions between identifiers, accounts, identities, or actors. Identity linking should preserve source, confidence, scope, evidence, and revocation state.
### 5. Keep concepts orthogonal
The model should minimize conceptual overlap. If two terms are similar, the repository should explain the distinction or deliberately collapse them with clear justification.
### 6. Remain implementation-neutral
The canonical model should be compatible with common IAM, directory, social graph, and authorization systems, but should not mirror any single product’s terminology too closely.
## Research Areas
The repository should collect and analyze knowledge from at least the following areas:
* SCIM, LDAP, and directory schemas;
* OpenID Connect, SAML, WebAuthn, and federation models;
* NIST digital identity guidelines and identity assurance terminology;
* Keycloak, ZITADEL, Ory, Authelia, LLDAP, and related IAM systems;
* ActivityPub, FOAF, WebID, Solid, and social graph models;
* Google Zanzibar, OpenFGA, Cedar, Cerbos, and relationship-based authorization;
* W3C DID and Verifiable Credentials;
* entity resolution, identity matching, and synonymity;
* GDPR-relevant concepts such as pseudonymization, data minimization, and identity linkage.
## Expected Outputs
The repository should eventually contain:
* a curated research corpus;
* a glossary of canonical identity-management terms;
* a terminology conflict map;
* a conceptual entity and relationship model;
* synonymity and identity-linking model notes;
* comparison notes against major standards and tools;
* model design principles;
* candidate schema sketches;
* recommendations for downstream implementation projects.
## Downstream Relationship
`identity-canon` may later inform projects such as:
* `user-engine` — operational user and account management;
* `user-accounts` — user-facing account and preference UI;
* `user-manager` — administrative user-management UI;
* `identity-connect` — adapters to IAM and directory systems;
* `actor-graph` — relationship and synonymity graph engine;
* `access-control` or related authorization projects;
* tenant, organization, community, and family management tooling.
These projects should treat `identity-canon` as a conceptual reference, not as an implementation dependency unless a later explicit schema package is extracted.
## Non-Goals
`identity-canon` is not intended to become:
* a replacement for Keycloak, LDAP, SCIM, OIDC, SAML, or OpenFGA;
* a complete authorization policy language;
* a production identity provider;
* a database product;
* a UI framework;
* a CLI implementation;
* a social network implementation.
Its value lies in making the terminology and conceptual structure clear enough that such systems can later be designed and integrated coherently.
## Guiding Question
The guiding question of `identity-canon` is:
> What is the smallest clear set of orthogonal concepts needed to model persons, accounts, identities, organizations, tenants, communities, families, agents, and their relationships across enterprise IAM, social systems, and multi-tenant platforms?
## Status
This repository begins as a research and terminology project. Its early work should prioritize clarity, comparison, and conceptual grounding over premature schema or implementation design.