generated from coulomb/repo-seed
145 lines
5.2 KiB
Markdown
145 lines
5.2 KiB
Markdown
# 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.
|