generated from coulomb/repo-seed
153 lines
5.5 KiB
Markdown
153 lines
5.5 KiB
Markdown
# Terminology Conflict Map
|
|
|
|
Status: draft. This map records high-risk terms whose meanings differ across
|
|
source families. It should be revised after each source-note backfill.
|
|
|
|
## Conflict: User
|
|
|
|
Problem: `user` can mean a person, account, login credential holder,
|
|
application profile, authorization subject, or product-facing actor.
|
|
|
|
Canonical stance: do not use `user` as a root concept. Require the writer to
|
|
choose among Natural Person, Account, Actor, Authenticated Subject, Principal,
|
|
Profile, or Persona.
|
|
|
|
Current mapping rule:
|
|
|
|
- If the system stores login state, map to Account.
|
|
- If the system renders a public or local display surface, map to Profile.
|
|
- If the system evaluates access, map to Principal or Authenticated Subject.
|
|
- If the text means a human being, map to Natural Person.
|
|
|
|
## Conflict: Identity
|
|
|
|
Problem: `identity` can mean selfhood, a directory record, an issuer-bound
|
|
subject, a set of claims, a DID, a credential, a profile, or an account.
|
|
|
|
Canonical stance: avoid bare `identity`. Prefer Identity Record, Identifier,
|
|
Claim, Credential, Profile, Persona, or Synonymity Assertion.
|
|
|
|
Current mapping rule:
|
|
|
|
- A persistent record about an actor maps to Identity Record.
|
|
- A value used to refer maps to Identifier.
|
|
- A statement made by an issuer maps to Claim.
|
|
- Proof material maps to Credential.
|
|
|
|
## Conflict: Account
|
|
|
|
Problem: account can mean login account, customer billing account, social
|
|
account, service account, or account profile.
|
|
|
|
Canonical stance: Account is an operational access record in a scope. Billing
|
|
or customer accounts need explicit relationship and commercial-role modeling.
|
|
|
|
Current mapping rule:
|
|
|
|
- Login-capable operational record maps to Account.
|
|
- Non-human login-capable record maps to Service Account.
|
|
- Commercial customer record maps to Customer relationship or Customer Account
|
|
only if a later source analysis justifies the separate concept.
|
|
|
|
## Conflict: Subject, Principal, Actor
|
|
|
|
Problem: protocols, authorization engines, and application models use these
|
|
terms differently. OIDC and SAML focus on subject identifiers; Cedar and IAM
|
|
often decide over principals; social and conceptual models talk about actors.
|
|
|
|
Canonical stance:
|
|
|
|
- Actor is the conceptual participant.
|
|
- Authenticated Subject is the issuer/protocol view after identification.
|
|
- Authorization Principal is the decision-engine projection.
|
|
|
|
The same natural person or account may appear as all three in different
|
|
contexts, but the concepts should not be merged.
|
|
|
|
## Conflict: Tenant, Realm, Organization, Customer
|
|
|
|
Problem: multi-tenant products often use tenant, organization, realm, customer,
|
|
workspace, project, and account as partial synonyms. Some are isolation
|
|
boundaries, some are legal or commercial actors, and some are administrative
|
|
containers.
|
|
|
|
Canonical stance:
|
|
|
|
- Tenant is an administrative or isolation scope.
|
|
- Realm is an issuer or administrative namespace unless source analysis proves
|
|
stronger tenant semantics.
|
|
- Organization is a collective actor or organizational structure.
|
|
- Customer is a commercial relationship role.
|
|
|
|
Model the relationships among these concepts instead of choosing one term to
|
|
stand for all of them.
|
|
|
|
## Conflict: Group, Role, Team, Community
|
|
|
|
Problem: IAM systems often use groups for role assignment, collaboration tools
|
|
use teams for work coordination, and social platforms use groups or communities
|
|
for participation.
|
|
|
|
Canonical stance:
|
|
|
|
- Group is a named collection or collective actor with membership.
|
|
- Role is a capability bundle or relationship label.
|
|
- Team is a domain-specific group or organization unit.
|
|
- Community is a participation-oriented collective actor.
|
|
|
|
Avoid modeling all four as generic `group`.
|
|
|
|
## Conflict: Member, Follower, Affiliate
|
|
|
|
Problem: membership, following, affiliation, employment, subscription, and
|
|
moderation relationships are often hidden behind `member`.
|
|
|
|
Canonical stance: relationship type matters. Represent each relationship with
|
|
source, target, scope, role or relation kind, evidence, lifecycle state, and
|
|
authorization implications if any.
|
|
|
|
## Conflict: Profile And Persona
|
|
|
|
Problem: profiles are sometimes account records, public pages, social
|
|
identities, or collections of claims. Personas are sometimes aliases,
|
|
pseudonyms, or UX-specific presentations.
|
|
|
|
Canonical stance:
|
|
|
|
- Profile is a presentation or attribute surface in a scope.
|
|
- Persona is a deliberate contextual presentation of an actor, often separate
|
|
from other presentations for privacy or role clarity.
|
|
|
|
## Conflict: Identifier, Credential, Claim
|
|
|
|
Problem: identifiers, credentials, and claims are often conflated because all
|
|
can appear in tokens, profiles, or identity documents.
|
|
|
|
Canonical stance:
|
|
|
|
- Identifier refers.
|
|
- Credential proves or supports.
|
|
- Claim states.
|
|
|
|
A token may contain all three, but the conceptual model should keep them apart.
|
|
|
|
## Conflict: Synonymity, Linking, Matching, Merge
|
|
|
|
Problem: identity systems often collapse weak matches, verified account links,
|
|
same-as claims, and destructive record merges into a single identity-linking
|
|
feature.
|
|
|
|
Canonical stance: synonymity is an assertion. It has source, target, scope,
|
|
confidence, evidence, method, lifecycle state, and privacy constraints. It does
|
|
not require destructive merging.
|
|
|
|
## Review Queue
|
|
|
|
- Validate each conflict against populated source notes.
|
|
- Add concrete examples and counterexamples once source summaries include
|
|
citations.
|
|
- Decide whether Customer Account deserves a canonical concept or stays a
|
|
downstream commercial model.
|
|
- Decide whether Realm should remain a Scope specialization or become a
|
|
separate canonical concept.
|