coulomb/identity-canon
Archived
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Seeded repo with initial and secondary research

Browse Source
This commit is contained in:
Bernd Worsch
2026-06-05 13:12:48 +02:00
parent 9067e75693
commit 6dc1f8311c
14 changed files with 1418 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

152
terminology/TerminologyConflictMap.md Normal file
View File

@@ -0,0 +1,152 @@
# 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.
## 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.
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.
## 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.
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.
Canonical stance: Account is an operational access record in a scope. Billing
or customer accounts need explicit relationship and commercial-role modeling.
Current mapping rule:
- 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.
## 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.
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.
## 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.
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.
Model the relationships among these concepts instead of choosing one term to
stand for all of them.
## 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.
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`.
## Conflict: Member, Follower, Affiliate
Problem: membership, following, affiliation, employment, subscription, and
moderation relationships are often hidden 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.
## 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.
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.
## Conflict: Identifier, Credential, Claim
Problem: identifiers, credentials, and claims are often conflated because all
can appear in tokens, profiles, or identity documents.
Canonical stance:
- Identifier refers.
- Credential proves or supports.
- Claim states.
A token may contain all three, but the conceptual model should keep them apart.
## 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.
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.
## 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.

72
terminology/TerminologyInventory.md Normal file
View File

@@ -0,0 +1,72 @@
# Terminology Inventory
Status: draft. This inventory is seeded from `ResearchProposal.md`,
`INTENT.md`, and the current research corpus index. Mappings are candidate
canonical mappings until the individual source notes have been backfilled with
real source summaries.
## Use
Use this file to collect source terms and their current candidate canonical
home. Use `terminology/TerminologyConflictMap.md` when a term is overloaded or
has incompatible meanings across source families.
## Inventory
| Term | Candidate canonical concept | Source families | Notes |
| --- | --- | --- | --- |
| actor | Actor | authorization, social graphs, proposal | Participation root for anything that can act or be acted for. |
| natural person | Natural Person | identity assurance, social graphs | Human being; never identical to an account or profile. |
| user | Convenience label only | SCIM, products, applications | Overloaded; map to Account, Actor, Subject, or Profile by context. |
| account | Account | SCIM, LDAP, IAM products | Operational record that enables access in a scope. |
| identity | Identity Record or Identity Claim | IAM, federation, DID, VC | Avoid as root noun; clarify whether record, claim, identifier, or social identity is meant. |
| identifier | Identifier | OIDC, SAML, DID, directories | A value or reference used to distinguish something in a scope. |
| credential | Credential | authentication, VC, DID | Evidence or secret material used to prove control, entitlement, or claim. |
| subject | Authenticated Subject | OIDC, SAML, authorization | Security-protocol view of an actor/account after identification by an issuer. |
| principal | Authorization Principal | Cedar, IAM, authorization | Entity considered by an authorization decision. |
| profile | Profile | social graphs, IAM, applications | Presentation or attribute surface for an actor/account in a scope. |
| persona | Persona | social/community systems | Deliberate contextual presentation of an actor, often with limited linkage. |
| agent | Artificial Agent | IAM, agentic systems | Non-human actor, including bot, service account, or AI agent. |
| bot | Artificial Agent | applications, social graphs | Automated actor; may act through an account and under delegation. |
| service account | Service Account | IAM, operations | Account intended for software or workload access rather than human login. |
| organization | Organization | SCIM, LDAP, Keycloak, ZITADEL | Collective actor or structure; do not collapse with tenant, legal entity, or customer. |
| legal entity | Legal Entity | business, compliance | Organization recognized under a legal system. |
| customer | Customer | SaaS, vendor/customer models | Commercial relationship role, not automatically a tenant or organization. |
| vendor | Vendor | SaaS, multi-vendor systems | Provider role in a commercial or operational relationship. |
| tenant | Tenant | SaaS, IAM products | Administrative or isolation scope; may be owned by or assigned to an organization. |
| realm | Realm | Keycloak, federation | Issuer or administrative namespace; candidate mapping is Scope or Tenant depending on use. |
| scope | Scope | OIDC, authorization, proposal | Boundary in which identifiers, policies, relationships, or meanings hold. |
| namespace | Scope | directories, DID, products | Naming boundary; treat as a kind of scope unless stronger semantics exist. |
| community | Community | social graphs, platforms | Collective actor defined by social participation rather than legal or customer status. |
| family | Family or Household | family account models | Relationship network with guardian/dependent semantics and privacy sensitivity. |
| household | Family or Household | family account models | Co-residence or account-management unit; may not equal legal family. |
| group | Group | LDAP, SCIM, social graphs, authz | Container or collective label; must not absorb relationship semantics. |
| team | Group or Organization Unit | SaaS, collaboration systems | Usually a collaboration group; sometimes an org sub-unit. |
| role | Role | RBAC, IAM products | Named capability set or relationship label; keep separate from group membership. |
| member | Membership Relationship | SCIM, groups, communities | Relationship from actor to collective actor or scope. |
| affiliation | Affiliation Relationship | enterprise, social | Looser association than membership; may be external or evidenced. |
| follower | Following Relationship | ActivityPub, social graphs | Directed social relationship, not a membership or authorization grant by default. |
| owner | Ownership Relationship | SaaS, authz | Control or responsibility relationship; needs scope and target. |
| administrator | Administration Relationship | IAM, SaaS | Delegated management authority in a scope. |
| delegation | Delegation Relationship | IAM, authz, agentic systems | Actor grants another actor authority to act in a bounded way. |
| representation | Representation Relationship | legal, org, agent systems | Actor acts on behalf of another actor or organization. |
| trust | Trust Relationship | federation, DID, authz | Reliance relationship; must record source, scope, and purpose. |
| claim | Claim | VC, OIDC, DID | Statement made by an issuer about a subject, actor, or relationship. |
| evidence | Evidence Source | entity resolution, assurance | Material supporting a claim or synonymity assertion. |
| assurance | Assurance Level | NIST, federation | Confidence about identity proofing, authentication, or binding. |
| identifier binding | Identifier Binding | federation, entity resolution | Assertion that an identifier refers to a target within a scope. |
| synonymity | Synonymity Assertion | entity resolution, proposal | Assertion that two records or identifiers refer to the same target under stated conditions. |
| weak match | Weak Synonymity Assertion | entity resolution | Probabilistic or low-confidence link; never a destructive merge. |
| strong link | Strong Synonymity Assertion | account linking, identity proofing | Verified or authoritative link; still scoped and evidenced. |
| pseudonym | Pseudonymous Identifier | privacy, OIDC, DID | Identifier designed to limit cross-scope correlation. |
| pairwise subject | Scoped Identifier | OIDC | Subject identifier scoped to relying party or sector; map to Identifier plus Scope. |
| relationship tuple | Relationship Assertion | Zanzibar, OpenFGA | Authorization-oriented representation of actor-object-relation facts. |
| policy | Authorization Projection | Cedar, IAM, authz | Rule artifact; not part of the canonical identity object model except as mapping. |
| lifecycle state | Lifecycle State | SCIM, IAM, directories | Activation, suspension, deletion, revocation, or archival state of a record or relationship. |
## Backfill Needs
- Add source-specific definitions from each file in `research/*/*.md`.
- Split terms that hide multiple meanings after source review.
- Add citation pointers once source notes contain stable references.
- Move mature canonical definitions to `canon/CanonicalGlossary.md`.