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

Complete IDENTITY-WP-0003 corpus backfill and model refinement

Browse Source 
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:
Bernd Worsch
2026-06-21 20:22:20 +02:00
parent 790a2f2041
commit 1c1b5c9bc6
32 changed files with 2676 additions and 623 deletions
Download Patch File Download Diff File Expand all files Collapse all files

226
terminology/TerminologyConflictMap.md
View File

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

158
terminology/TerminologyInventory.md
View File

@@ -1,9 +1,8 @@
# 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.
Status: draft. Updated after IDENTITY-WP-0003 corpus backfill. Mappings remain
candidate until reviewed against `canon/CanonicalGlossary.md` and scenario
tests.
## Use
@@ -15,58 +14,103 @@ has incompatible meanings across source families.
| 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. |
| actor | Actor | ActivityPub, FOAF, Cedar, proposal | Participation root. ActivityPub actor is server-hosted; FOAF Agent includes persons. |
| natural person | Natural Person | FOAF, Schema.org, NIST, GDPR | Human being; FOAF Person and Schema.org Person align strongly. |
| user | Convenience label only | SCIM, LDAP, Keycloak, ZITADEL, apps | Overloaded. Map by context: SCIM/LDAP User → Identity Record; Keycloak/ZITADEL User → Account. |
| account | Account | SCIM, LDAP posixAccount, FOAF OnlineAccount, Keycloak | Operational access record in a scope. FOAF separates account from person explicitly. |
| identity | Identity Record or Claim | Kratos, OIDC, DID, VC, apps | Kratos Identity = traits + credentials. Avoid bare `identity` as root noun. |
| identifier | Identifier | OIDC sub, SAML NameID, LDAP DN, DID, WebID | Value referring within or across scopes. See Scoped Identifier when correlation is limited. |
| scoped identifier | Scoped Identifier | OIDC pairwise, SAML transient, pseudonyms | Meaning limited to RP, sector, tenant, or session. |
| credential | Credential | NIST, Kratos, OIDC token, VC, DID keys | Proof material. Distinguish VC (claim container) from password/WebAuthn. |
| subject | Authenticated Subject | OIDC, SAML, SSF events | Protocol/security view after issuer identification. Not Actor or Principal. |
| principal | Authorization Principal | Cedar, Cerbos, Zanzibar, OpenFGA | Decision-engine participant. OpenFGA `user:` prefix is not a human user. |
| end-user | Natural Person (inferred) | OIDC | OIDC names the human implicitly; does not model as entity. |
| profile | Profile | FOAF, WebID/Solid, SCIM attrs, ActivityPub | Presentation or attribute surface. Solid profile is user-controlled data. |
| persona | Persona | proposal, privacy patterns | Contextual presentation; pairwise/pseudonymous profiles map here. |
| agent | Actor or Artificial Agent | FOAF, ActivityPub, WebID | FOAF Agent includes humans; ActivityPub Service = Artificial Agent. |
| bot | Artificial Agent | ActivityPub Service, apps | Automated actor; may use Service Account. |
| service account | Service Account | Keycloak, ZITADEL machine user, Kratos | Non-human login or API identity. ZITADEL machine user, Kratos service patterns. |
| machine user | Service Account | ZITADEL | Product term for non-human org identity. |
| organization | Organization | Schema.org, Keycloak Orgs, ZITADEL, SCIM ext | Collective actor. SCIM `organization` attribute is not an Organization actor. |
| legal entity | Legal Entity | business, compliance | Organization recognized under law; separate from tenant. |
| customer | Customer | SaaS, vendor models | Commercial relationship role. ZITADEL org often plays customer tenant role. |
| vendor | Vendor | SaaS, multi-vendor | Provider role in commercial relationship. |
| tenant | Tenant | ZITADEL org, SaaS, Keycloak (informal) | Administrative/isolation scope. Keycloak realm sometimes called tenant. |
| realm | Realm | Keycloak | Hard identity/admin namespace. Candidate Scope specialization. |
| scope | Scope | OIDC, Cerbos, OpenFGA store, proposal | Boundary for meaning, policy, or correlation. |
| namespace | Scope | LDAP dc, Keto/OpenFGA, DID method | Naming or authorization partition. |
| instance | Scope | ZITADEL | Deployment-level boundary above organizations. |
| project | Application Scope | ZITADEL | Application/product container within org. |
| community | Community | ActivityPub Group, proposal | Participation-oriented collective. ActivityPub Group may be Community or Group. |
| family | Family or Household | proposal, GDPR-sensitive | Guardian/dependent semantics; privacy-sensitive. |
| household | Family or Household | family accounts | Co-residence unit; may differ from legal family. |
| group | Group | LDAP, SCIM, FOAF, ActivityPub, Cedar | Named collection. LDAP/SCIM group ≠ social community without context. |
| team | Group or Organization Unit | Schema.org, collaboration | Collaboration unit; may be org sub-unit. |
| role | Role | Keycloak, ZITADEL, Cedar, Cerbos, Schema.org OrganizationRole | Capability bundle or relationship label. Cerbos derived role may hide Ownership. |
| grant | Role assignment | ZITADEL | Project role assignment; map to Delegation-like relationship. |
| member | Membership Relationship | SCIM, LDAP, FOAF, Schema.org, Zanzibar | Relationship edge, not a noun for the participant. |
| affiliation | Affiliation Relationship | Schema.org, FOAF knows | Looser than membership. FOAF knows is weak social affiliation. |
| follower | Following Relationship | ActivityPub | Directed social subscription; not membership or authz. |
| follow | Following Relationship | ActivityPub | Activity establishing follower edge. |
| owner | Ownership Relationship | Zanzibar, Cerbos derived | Control/responsibility. Cerbos may encode as attribute not relationship. |
| administrator | Administration Relationship | IAM, ZITADEL grants | Delegated management in scope. |
| delegation | Delegation Relationship | Cedar context, agents | Bounded authority grant. Cedar context may carry delegatedBy. |
| representation | Representation Relationship | SCIM manager, DID controller | Acting on behalf of another. DID controller may differ from subject. |
| trust | Trust Relationship | federation, VC, DID | Reliance on issuer/verifier; federation metadata trust. |
| claim | Claim | OIDC, SAML attributes, VC | Statement by issuer. SAML AttributeStatement → Claim. |
| evidence | Evidence Source | NIST proofing, entity resolution, SSF | Supports claims and synonymity. SSF SET = event Evidence Source. |
| assurance | Assurance Level | NIST IAL/AAL/FAL | Orthogonal identity, authentication, federation confidence. |
| identifier binding | Identifier Binding | OIDC iss+sub, WebID-OIDC, SAML | Assertion that identifier refers to target in scope. |
| synonymity | Synonymity Assertion | entity resolution, OIDC linking, schema.org sameAs | Scoped evidenced equivalence. sameAs is weak by default. |
| weak match | Weak Synonymity Assertion | probabilistic matching | Probabilistic link; never destructive merge. |
| strong link | Strong Synonymity Assertion | deterministic match, verified linking | Authoritative or verified; still scoped. |
| same_as | Synonymity Assertion (strong) | synonymity model | High-confidence equivalence relation type. |
| probably_same_as | Synonymity Assertion (weak) | probabilistic matching | Probabilistic equivalence relation type. |
| linked_to | Synonymity Assertion (operational) | account linking | Convenience link without semantic sameness claim. |
| pseudonym | Pseudonymous Identifier | GDPR, OIDC pairwise | Limits cross-scope correlation. |
| pairwise subject | Scoped Identifier | OIDC | RP-specific sub preventing global correlation. |
| relationship tuple | Relationship Tuple | Zanzibar, OpenFGA, Keto | Authz projection: subject#relation@object. |
| policy | Authorization Projection | Cedar, Cerbos | Rule artifact; downstream of canon model. |
| lifecycle state | Lifecycle State | SCIM active, SSF/RISC events, VC status | Applies to records, credentials, relationships, assertions. |
| subscriber | Account / Identity Record | NIST | Enrolled party at CSP; not synonymous with Natural Person until IAL binding. |
| issuer | Scope + Trust Relationship | OIDC iss, VC issuer, SAML IdP | Namespace authority for identifiers and claims. |
| relying party | Scope | OIDC RP, SAML SP, NIST | Consumer of assertions; RP-local account binding. |
| nameid | Identifier | SAML | Format attribute determines persistence and privacy semantics. |
| distinguished name | Identifier | LDAP | Compound locator in directory namespace. |
| externalid | Identifier | SCIM | Client-supplied cross-system correlation key. |
| traits | Profile attributes | Kratos | Schema-validated identity attributes. |
| verification method | Credential | DID Core | Cryptographic key in DID document. |
| verifiable credential | Credential + Claim | VC Data Model | Signed claim set; distinct from login credential. |
| holder | Actor (custody role) | VC, OpenID4VC | Party possessing VC; may differ from subject. |
| verifier | Scope (evaluation role) | VC, OpenID4VC | Validates presentations. |
| did | Identifier | DID Core | Decentralized identifier with method-specific resolution. |
| webid | Identifier | WebID/Solid | HTTP URI identifying agent with dereferenceable profile. |
| data subject | Natural Person | GDPR | Identifiable natural person for privacy regulation. |
| pseudonymization | Processing pattern | GDPR | Technique; maps to Scoped Identifier + separated re-id key. |
| controller | Organization (legal role) | GDPR | Downstream legal role; not canonical identity root. |
| tuple (authz) | Relationship Tuple | Zanzibar | Authorization fact, not social relationship. |
| userset | Authorization Principal (indirect) | Zanzibar, OpenFGA | Subject referenced via relation chain. |
| derived role | Role (computed) | Cerbos | Role from attributes; should trace to Relationship when possible. |
| contextual tuple | Delegation context | OpenFGA | Ephemeral authz fact at check time. |
| sameas | Weak Synonymity Assertion | Schema.org | Informal web equivalence; not strong link without evidence. |
| organizationrole | Role + Membership | Schema.org | Temporal role with start/end dates. |
| assurance level change | Assurance Level update | SSF/CAEP | Event affecting IAL/AAL/FAL metadata. |
## Backfill Needs
## Source Note Citations
- 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`.
Terms above are grounded in backfilled notes under:
- `research/identity-provisioning/` (5 notes)
- `research/authentication-federation/` (4 notes)
- `research/authorization-relationships/` (4 notes)
- `research/social-community-graphs/` (4 notes)
- `research/verifiable-claims/` (3 notes)
- `research/entity-resolution-privacy/` (3 notes)
## Remaining Backfill Needs
- Split `group` into authorization group vs. social collective where sources
disagree (OpenFGA member vs. ActivityPub follower).
- Add product-version qualifiers when Keycloak/ZITADEL models evolve.
- Promote stable mappings to `canon/CanonicalGlossary.md` after scenario
review.