identity-canon/terminology/TerminologyConflictMap.md

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

• 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.