5.5 KiB
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.