# Terminology Conflict Map

Status: draft. Revised after IDENTITY-WP-0003 corpus backfill. Each conflict
includes source-backed examples from populated research notes.

## Conflict: User

Problem: `user` can mean a person, account, login credential holder,
application profile, authorization subject, or product-facing actor.

Source evidence:

- SCIM User = provisionable Identity Record (`scim-rfc7643-rfc7644.md`)
- Keycloak/ZITADEL User = Account with credentials (`keycloak-organizations.md`,
  `zitadel-organizations-projects.md`)
- OpenFGA `user:` tuple prefix = Authorization Principal id (`openfga-modeling.md`)
- OIDC End-User = implied Natural Person, not modeled (`oidc-core-subject-identifiers.md`)

Canonical stance: do not use `user` as a root concept.

Current mapping rule:

- Provisioning record (SCIM/LDAP) → Identity Record
- Login-enabled product record → Account
- Public/local display → Profile
- Access evaluation → Principal or Authenticated Subject
- Human being → 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.

Source evidence:

- Kratos Identity = traits + credentials (`ory-kratos-keto.md`)
- OIDC developers conflate `sub` with "identity" (`oidc-core-subject-identifiers.md`)
- DID is identifier, not identity record (`did-core.md`)
- VC credentialSubject = claims about subject (`vc-data-model-2.md`)

Canonical stance: avoid bare `identity`. Prefer Identity Record, Identifier,
Claim, Credential, Profile, Persona, or Synonymity Assertion.

## Conflict: Account

Problem: account can mean login account, customer billing account, social
media handle, service account, or FOAF online presence.

Source evidence:

- FOAF OnlineAccount is service presence, explicitly not Person (`foaf-agent-person-group-onlineaccount.md`)
- LDAP posixAccount is attribute bundle on person entry (`ldap-rfc4519-inetorgperson-rfc2798.md`)
- ActivityPub `acct:` URI suggests account but actor is richer (`activitypub-actors-followers.md`)
- ZITADEL machine user = Service Account (`zitadel-organizations-projects.md`)

Canonical stance: Account is operational access record in a scope. Billing
records map to Commercial Record; commercial parties use Customer/Vendor roles
and Commercial Relationship.

## Conflict: Subject, Principal, Actor

Problem: protocols, authorization engines, and social models overload these terms.

Source evidence:

- OIDC Subject = issuer-scoped identifier (`oidc-core-subject-identifiers.md`)
- SAML Principal = authenticated subject in assertion (`saml-nameid-federation.md`)
- Cedar Principal = typed entity in authorization request (`cedar-principal-action-resource-context.md`)
- Zanzibar/OpenFGA Subject = opaque authz participant (`zanzibar-rebac.md`)
- ActivityPub Actor = server-hosted social entity (`activitypub-actors-followers.md`)
- FOAF Agent = actionable entity, includes Person (`foaf-agent-person-group-onlineaccount.md`)
- GDPR Data Subject = natural person (`gdpr-pseudonymization.md`)

Canonical stance:

- Actor = conceptual participant
- Authenticated Subject = issuer/protocol view
- Authorization Principal = decision-engine projection

## Conflict: Tenant, Realm, Organization, Customer

Problem: multi-tenant products collapse isolation boundaries and commercial actors.

Source evidence:

- Keycloak Realm = hard namespace; Organization = B2B overlay (`keycloak-organizations.md`)
- ZITADEL Organization = customer boundary + org actor (`zitadel-organizations-projects.md`)
- SCIM has no tenant; org is string attribute (`scim-rfc7643-rfc7644.md`)
- Schema.org Organization = collective actor (`schema-org-person-organization-membership.md`)

Canonical stance:

- Tenant = administrative/isolation scope
- Realm = issuer/admin namespace (Scope specialization)
- Organization = collective actor
- Customer = commercial relationship role

Model relationships among them; do not synonymize.

## Conflict: Group, Role, Team, Community

Problem: IAM groups, collaboration teams, social communities, and authz member
relations use overlapping labels.

Source evidence:

- LDAP/SCIM Group = entry with member references (`ldap`, `scim` notes)
- ActivityPub Group actor = collective social actor (`activitypub-actors-followers.md`)
- Zanzibar `group#member@user` = authz tuple (`zanzibar-rebac.md`)
- Cerbos derived role from group attribute (`cerbos-abac-derived-roles.md`)
- Schema.org Organization subtypes include SportsTeam (`schema-org` note)

Canonical stance:

- Group = named collection with membership
- Role = capability bundle or relationship label
- Team = collaboration group or org unit
- Community = participation-oriented collective actor

## Conflict: Member, Follower, Affiliate

Problem: membership, following, affiliation, and authz member relations hide
distinct semantics behind `member`.

Source evidence:

- ActivityPub Follow ≠ membership (`activitypub-actors-followers.md`)
- Schema.org affiliation looser than memberOf (`schema-org-person-organization-membership.md`)
- OpenFGA organization#member = authz projection (`openfga-modeling.md`)
- FOAF member = group membership; knows = acquaintance (`foaf` note)

Canonical stance: use typed relationships with scope and evidence.

## Conflict: Profile And Persona

Problem: profiles are account records, RDF documents, public pages, or VC subjects.

Source evidence:

- WebID profile document = RDF at URI (`webid-solid-profile.md`)
- Kratos traits often called profile informally (`ory-kratos-keto.md`)
- ActivityPub actor profile = public actor representation
- Persona for pairwise/pseudonymous scoped presentation (OIDC, GDPR notes)

Canonical stance:

- Profile = presentation surface in scope
- Persona = deliberate contextual presentation with privacy boundaries

## Conflict: Identifier, Credential, Claim

Problem: tokens and documents bundle all three.

Source evidence:

- OIDC ID Token contains sub (identifier) and claims (`oidc-core-subject-identifiers.md`)
- VC = signed claims with proof (`vc-data-model-2.md`)
- DID verification method = cryptographic credential (`did-core.md`)
- SAML AttributeStatement = claims; NameID = identifier (`saml-nameid-federation.md`)

Canonical stance: identifier refers; credential proves; claim states.

## Conflict: Synonymity, Linking, Matching, Merge

Problem: systems collapse probabilistic matches, verified links, and destructive
merges into one feature.

Source evidence:

- Probabilistic matching → weak assertion (`deterministic-vs-probabilistic-matching.md`)
- OIDC iss+sub binding → strong scoped assertion (`oidc`, `synonymity-assertions` notes)
- Schema.org sameAs = weak web equivalence (`schema-org` note)
- GDPR cross-linking raises identifiability risk (`gdpr-pseudonymization.md`)
- MDM golden record merge = downstream anti-pattern (`deterministic` note)

Canonical stance: synonymity is scoped, evidenced, revocable assertion.

## Conflict: Credential (Auth) vs. Verifiable Credential

Problem: "credential" means password, OIDC token, or W3C VC.

Source evidence:

- NIST authenticator/credential (`nist-800-63-4.md`)
- VC Data Model verifiable credential (`vc-data-model-2.md`)
- OpenID4VC bridges OAuth credential terminology with VCs (`openid4vc.md`)

Canonical stance: use Credential with context. VC maps to Credential containing
Claims; login secrets map to Credential (authentication factor).

## Conflict: Issuer

Problem: issuer means OIDC OP, VC issuer, SAML IdP, or CSP.

Source evidence:

- OIDC iss claim defines subject namespace (`oidc-core-subject-identifiers.md`)
- VC issuer signs credential (`vc-data-model-2.md`)
- NIST CSP performs proofing (`nist-800-63-4.md`)

Canonical stance: Issuer = Scope authority + Trust Relationship; specify protocol
role when mapping.

## Conflict: Customer Account

Problem: `customer account` collapses login account, B2B subscriber organization,
Stripe billing customer, and CRM account into one product noun.

Source evidence:

- Auth0 uses Subscriber for tenant holder, not customer account (`b2b-saas-subscriber-tenancy.md`)
- Stytch: organization is the customer (`b2b-saas-subscriber-tenancy.md`)
- Stripe Customer is billing object with subscriptions, not login (`stripe-customer-billing.md`)
- ZITADEL/Keycloak org-as-tenant has no Customer Account type (`zitadel`, `keycloak` notes)

Canonical stance: **reject Customer Account** as canonical term. Resolve by layer:

- login/access → Account;
- subscribing company → Organization + Customer role + Tenant;
- billing/CRM → Commercial Record;
- vendor↔customer link → Commercial Relationship.

## Review Queue

- [x] Customer Account — resolved; use Commercial Record + Commercial Relationship.
- [ ] Decide Realm specialization — Keycloak evidence supports Realm as Scope
  specialization; promote in glossary if scenario review confirms.
- [ ] Split authz `member` relation from social Membership in downstream adapters.
- [ ] Classify schema.org sameAs default strength — corpus says weak only.
- [ ] Standardize assurance dimensions — NIST IAL/AAL/FAL as orthogonal metadata.