--- a/README.md +++ b/README.md @@ -1,12 +1,16 @@ -# identity-canon +# commerce-canon -Orthogonal vocabulary and canonical model for identity-related concepts. +CommerceCanon owns counterparty and commercial-relationship semantics and imports +shared identity, organization, access, governance, and evidence concepts from +InfoTechCanon. Custodian canon governs both domain canons. -Start with: +This repository continues the history of `identity-canon` under accepted +CUST-ADR-006. The federation migration is coordinated by +[CFED-WP-0001](../prj-canon-federation/workplans/CFED-WP-0001-foundation.md). +The existing glossary and research remain migration inputs until the destination +models pass their canon review gates; the rename alone does not publish them. -- `INTENT.md` for purpose and project boundaries; -- `ResearchProposal.md` for the research method and expected deliverables; -- `research/CorpusIndex.md` for the source-note corpus; -- `canon/CanonicalGlossary.md` and `model/ConceptualModel.md` for the current - draft canon; -- `workplans/` for State Hub-tracked work. +Start with [INTENT.md](INTENT.md), [SCOPE.md](SCOPE.md), the +[research corpus](research/CorpusIndex.md), and [workplans](workplans/). +The [migration ledger](../prj-canon-federation/ledger/README.md) records concept +destinations. The new canon layout is tracked by CFED-WP-0001-T04. --- a/INTENT.md +++ b/INTENT.md @@ -1,168 +1,23 @@ -# INTENT.md +# Intent -## Purpose +CommerceCanon provides researched, implementation-neutral semantics for +counterparties, legal/commercial roles, commercial relationships and commitments, +payment references, and counterparty assurance. -`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. +Each concept has one owner. Commerce imports shared concepts from InfoTechCanon +rather than redefining actors, accounts, identifiers, authorization, or evidence. +For example, Commerce owns Registry Identifier as a specialization of the shared +Identifier; Adjudication Outcome is imported from the evidence model. -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. +This repository continues the research and Git history of identity-canon under +CUST-ADR-006, accepted 2026-08-17. Existing identity research migrates to its owning +canon through the project ledger. Research remains provenance; draft definitions +require destination review before publication. -## Core Intent +New commercial content requires a demand signal with named consumer evidence. +Potential consumers include fin-hub, target-revenue, adaptive-pricing, and +qonto-assistant; their adoption is not a federation completion gate. -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. - +CommerceCanon provides semantics and research. Runtime services, APIs, CLI tools, +application integrations, and speculative expansion require separate demand and +work records. Ecosystem policy remains in Custodian canon. --- a/SCOPE.md +++ b/SCOPE.md @@ -1,54 +1,32 @@ -# SCOPE +# Scope -## One-liner +CommerceCanon owns counterparty and commercial-relationship semantics under +CUST-ADR-006. Its shared technical concepts are imported from InfoTechCanon. -Orthogonal vocabulary and canonical model for identity-related concepts. +## In scope -## Core Idea +- Preserve the existing research corpus, scenarios, terminology, Git history, + and finished IDENTITY-WP workplans as provenance. +- Implement the commerce assignments in the federation ownership ledger. +- Establish the canon layout, kernel boundary, and reciprocal interface cards. +- Separate commercial records from login accounts and model commercial binding + explicitly, carrying forward design principles P14 and P15. +- Grow through named consumer demand; record implementation in local workplans. -`identity-canon` is a research and terminology repository. It defines an -implementation-neutral vocabulary and conceptual model for identity, accounts, -actors, organizations, tenants, communities, families, agents, relationships, -and synonymity across IAM, directory, federation, social graph, authorization, -decentralized identity, and entity-resolution domains. +## Out of scope -## In Scope +- Re-own identity, organization, access-control, governance, or general evidence + concepts; redefine Adjudication Outcome in CommerceCanon. +- Implement runtime identity or payment services, production APIs, or a CLI. +- Author Family beyond the separately owned seed or speculative new commercial + concepts. Consumer adoption is separately owned. -- Maintain research notes, source summaries, terminology inventories, - conflict maps, canonical glossary entries, conceptual model notes, scenario - tests, open questions, downstream recommendations, and State Hub workplans. -- Compare overlapping terms across standards, product documentation, social - graph models, authorization systems, and privacy/entity-resolution research. -- Keep canonical definitions separate from external product mappings. -- Record decisions, progress, and workplan status through State Hub. -- Verify changes with markdown review, `git diff --check`, and ADR-001 - consistency checks. +## Migration status -## Out of Scope +The repository rename preserves history. The old mixed glossary remains a +migration input until CFED-WP-0001-T04/T05/T06/T07 establish the destination +layout, models, and provenance distribution. Rename completion does not imply +those publication gates have passed. -- Implement identity providers, account-management services, provisioning - adapters, authorization engines, UI components, CLI commands, databases, or - production APIs. -- Own unrelated adjacent systems or operational identity lifecycle tooling. -- Make irreversible operational decisions without human approval. -- Treat draft canon artifacts as finalized schemas before source-note backfill - and scenario review. - -## Current State - -- Status: active research scaffold. -- The repository is currently documentation-only. It has no package manifest, - build system, runtime app, or executable test suite. -- `IDENTITY-WP-0002` seeded the first terminology, canon, model, scenario, - open-question, and downstream recommendation artifacts. The next research - pass should backfill individual source notes and revise the draft canon from - evidence. - -## Getting Oriented - -- Start with: INTENT.md -- Research proposal: ResearchProposal.md -- Corpus index: research/CorpusIndex.md -- Draft canon: canon/CanonicalGlossary.md and model/ConceptualModel.md -- Agent instructions: AGENTS.md -- Workplans: workplans/ +See INTENT.md, research/CorpusIndex.md, and the federation ledger. New plans use +COMMERCE-WP-; existing IDENTITY-WP identifiers and finished files remain intact. --- a/.repo-classification.yaml +++ b/.repo-classification.yaml @@ -1,17 +1,16 @@ repo_classification: standard: Repo Classification Standard version: '1.0' - classified_at: '2026-06-22' - classified_by: human + classified_at: '2026-09-05' + classified_by: codex category: research - domain: infotech + domain: financials secondary_domains: - government + - infotech capability_tags: - - identity - - access-control + - canon - terminology - - canon - governance business_stake: - technology @@ -22,4 +21,8 @@ - intention - control - adaptation - notes: Identity canon; standard §13.3 — human confirmed. + notes: >- + CommerceCanon continues identity-canon history under CUST-ADR-006 accepted + 2026-08-17 and CFED-WP-0001-T03. Financials is primary for counterparty and + commercial semantics; government and infotech capture its regulatory and + imported technical boundaries. Research category is retained during migration. --- /dev/null +++ b/history/2026-09-05-commerce-rename-preparation.md @@ -0,0 +1,16 @@ +# CommerceCanon rename preparation — 2026-09-05 + +CUST-ADR-006 and CFED-WP-0001 authorize renaming identity-canon in place to +commerce-canon. State Hub repository UUID is +8c82baea-bb40-435d-ac42-ec7a7c20dbb8; verified Forgejo repository ID is 46. +The three finished IDENTITY-WP workplans remain unchanged. New plans after +cutover use COMMERCE-WP; the pre-cutover IDENTITY-WP-0004 retains its ID. + +Preparation baseline: 43c5c21a7a7e273241d9c7622db4e926ac9aadfa. This is a +preparation record, not evidence that the rename completed. Record the final +operation ID, cutover date/head, continuity verification, registered-host +outcomes, and metadata commit in the rename workplan at execution. + +Identity and evidence content move to InfoTechCanon through the ownership ledger; +commercial content stays here. Research and historical references remain +provenance. Runtime implementation and downstream adoption are separately owned.