generated from coulomb/repo-seed
Complete IDENTITY-WP-0003 corpus backfill and model refinement
Backfill all 23 research source notes with terminology extracts, modeling assumptions, conflicts, canonical mappings, and references. Refresh terminology artifacts, refine the conceptual model with explicit scenario paths, reconcile canon surfaces and open questions, and mark the workplan finished.
This commit is contained in:
@@ -1,152 +1,210 @@
|
||||
# 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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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:
|
||||
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
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.
|
||||
media handle, service account, or FOAF online presence.
|
||||
|
||||
Canonical stance: Account is an operational access record in a scope. Billing
|
||||
or customer accounts need explicit relationship and commercial-role modeling.
|
||||
Source evidence:
|
||||
|
||||
Current mapping rule:
|
||||
- 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`)
|
||||
|
||||
- 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.
|
||||
Canonical stance: Account is operational access record in a scope.
|
||||
|
||||
## 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.
|
||||
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 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.
|
||||
- Actor = conceptual participant
|
||||
- Authenticated Subject = issuer/protocol view
|
||||
- Authorization Principal = decision-engine projection
|
||||
|
||||
## 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.
|
||||
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 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.
|
||||
- Tenant = administrative/isolation scope
|
||||
- Realm = issuer/admin namespace (Scope specialization)
|
||||
- Organization = collective actor
|
||||
- Customer = commercial relationship role
|
||||
|
||||
Model the relationships among these concepts instead of choosing one term to
|
||||
stand for all of them.
|
||||
Model relationships among them; do not synonymize.
|
||||
|
||||
## 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.
|
||||
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 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`.
|
||||
- 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, employment, subscription, and
|
||||
moderation relationships are often hidden behind `member`.
|
||||
Problem: membership, following, affiliation, and authz member relations hide
|
||||
distinct semantics 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.
|
||||
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 sometimes account records, public pages, social
|
||||
identities, or collections of claims. Personas are sometimes aliases,
|
||||
pseudonyms, or UX-specific presentations.
|
||||
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 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.
|
||||
- Profile = presentation surface in scope
|
||||
- Persona = deliberate contextual presentation with privacy boundaries
|
||||
|
||||
## Conflict: Identifier, Credential, Claim
|
||||
|
||||
Problem: identifiers, credentials, and claims are often conflated because all
|
||||
can appear in tokens, profiles, or identity documents.
|
||||
Problem: tokens and documents bundle all three.
|
||||
|
||||
Canonical stance:
|
||||
Source evidence:
|
||||
|
||||
- Identifier refers.
|
||||
- Credential proves or supports.
|
||||
- Claim states.
|
||||
- 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`)
|
||||
|
||||
A token may contain all three, but the conceptual model should keep them apart.
|
||||
Canonical stance: identifier refers; credential proves; claim states.
|
||||
|
||||
## 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.
|
||||
Problem: systems collapse probabilistic matches, verified links, and destructive
|
||||
merges into one 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.
|
||||
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.
|
||||
|
||||
## 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.
|
||||
- [ ] Decide Customer Account canonical concept — ZITADEL org-as-customer suggests
|
||||
Organization + Tenant link, not separate Customer Account entity.
|
||||
- [ ] 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.
|
||||
Reference in New Issue
Block a user