generated from coulomb/repo-seed
tegwick
3ccf841095
Record B2B SaaS subscriber tenancy and Stripe billing source notes. Resolve the Customer Account open question: reject it as canonical, add Commercial Record and Commercial Relationship to the Record and relationship layers, and document Subscriber as a convenience term only.
230 lines
9.0 KiB
Markdown
230 lines
9.0 KiB
Markdown
# 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. |