identity-canon/model/ConceptualModel.md

Conceptual Model

Status: draft. This is the first narrative model extracted from the research proposal. It is intentionally implementation-neutral and should be refined by source-note backfill and scenario testing.

Core Claim

Identity-canon should model identity-related systems as scoped actors, records, identifiers, claims, credentials, relationships, and projections. The model should keep social, legal, operational, authentication, and authorization meanings visible instead of collapsing them into user, group, or tenant.

Entity Families

Actor Layer

• Actor: participation root.
• Natural Person: human actor.
• Artificial Agent: non-human automated actor.
• Collective Actor: actor composed of, representing, or organizing multiple actors.
• Organization, Community, Family or Household, Group, and Team: candidate collective actor specializations.

Record Layer

• Account: operational access record in a scope.
• Service Account: software-oriented account.
• Identity Record: source-specific record about an actor or account.
• Profile: presentation or attribute surface.
• Persona: contextual presentation of an actor.

Reference Layer

• Identifier: value or reference within a scope.
• Scoped Identifier: identifier designed for limited correlation.
• Credential: proof or control material.
• Claim: statement made by a source or issuer.
• Evidence Source: support for claims, relationships, and synonymity.

Scope Layer

• Scope: boundary for meaning.
• Tenant: administrative or isolation scope.
• Realm: issuer or security namespace.
• Namespace: naming scope.
• Authorization Domain: scope in which principals, resources, actions, and policies are evaluated.

Projection Layer

• Authenticated Subject: protocol projection of an identified entity.
• Authorization Principal: decision-engine projection of an actor, account, or subject.
• Authorization Resource, Action, Policy, and Relationship Tuple: downstream authorization projections, not canonical identity roots.

Relationship Classes

Relationships should be explicit model elements when they affect meaning, authorization, privacy, or lifecycle.

Core relationship classes:

• Membership: actor participates in a collective actor or scope.
• Affiliation: actor is associated with another actor or collective.
• Following: actor subscribes to or follows another actor or profile.
• Ownership: actor controls or is responsible for a record, resource, tenant, or organization.
• Representation: actor acts on behalf of another actor.
• Delegation: actor grants bounded authority to another actor.
• Administration: actor manages records, relationships, or configuration in a scope.
• Trust: actor, issuer, verifier, or system relies on another for a purpose.
• Synonymity: records or identifiers are asserted to refer to the same target under stated evidence and scope.

Recommended relationship fields:

• relationship type;
• source and target;
• scope;
• source system or issuer;
• evidence reference;
• confidence or assurance when relevant;
• lifecycle state;
• privacy constraints;
• authorization implication, if any.

Identity Linking Model

Identity linking should not merge records by default. It should create Synonymity Assertions.

Weak synonymity examples:

• imported records match on name and email hash;
• two profiles share a phone number but lack explicit verification;
• an entity-resolution job proposes a duplicate.

Strong synonymity examples:

• account holder completes explicit account-linking flow;
• issuer signs a claim binding an identifier to a subject;
• operator verifies a link against authoritative evidence.

Privacy-limited synonymity examples:

• pairwise subject identifier bound only for one relying party;
• pseudonymous community profile linked only inside a restricted scope;
• legal identity reference stored separately from a public persona.

Invariants

• A Natural Person can control zero, one, or many Accounts.
• An Account belongs to exactly one primary operational Scope, but can have relationships to other scopes.
• A Profile presents an Actor, Account, or Persona within a Scope.
• A Principal is a projection for authorization and should not replace Actor or Account in the canon.
• A Tenant can be related to an Organization or Customer, but should not be treated as identical to either.
• A Group can carry Membership relationships, but Role assignment and relationship semantics must stay explicit.
• A Synonymity Assertion can link records without destroying source identity or evidence.
• Lifecycle state applies to relationships and assertions, not only accounts.

External Mapping Rule

When mapping an external system, first identify which canonical layer the source term belongs to:

1. Actor layer: who or what participates?
2. Record layer: what operational record exists?
3. Reference layer: what values, claims, or credentials refer or prove?
4. Scope layer: where is the meaning valid?
5. Relationship layer: what typed connection is asserted?
6. Projection layer: what downstream protocol or authorization view is needed?

Only after that mapping should source-specific labels such as user, group, organization, realm, tenant, subject, or principal be adopted in a downstream artifact.