Distribute frozen federation corpus by concept destination
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
This commit is contained in:
parent
3e3191549a
commit
372f671eef
81 changed files with 14146 additions and 99 deletions
|
|
@ -0,0 +1,230 @@
|
|||
# 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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue