# Canonical Glossary Status: draft. Updated after IDENTITY-WP-0003 corpus backfill and scenario review. Definitions remain candidate canon terms until human review promotes them. ## Actor An entity that can participate in relationships, hold or control accounts, be represented by another actor, or be projected into downstream systems. Includes: natural persons, organizations, communities, families, service accounts, bots, and AI agents. Excludes: raw identifiers, credentials, claims, and profiles unless they are being represented as records about an actor. ## Natural Person A human being. A natural person may have many accounts, profiles, identifiers, credentials, personas, and relationships. Excludes: account records, social profiles, legal entities, and artificial agents. ## Artificial Agent A non-human actor that performs actions under software, automation, or delegated control. Includes: bots, service agents, workloads, and AI agents. ## Collective Actor An actor composed of or associated with multiple actors. Includes: organizations, communities, families, households, groups, and teams when they can participate in relationships or be represented. ## Account An operational record in a scope that enables access, login, administration, or system participation. Includes: human login accounts and service accounts. Excludes: natural persons, billing accounts, profiles, credentials, and authorization principals unless a source uses account in that narrower context. ## Service Account An account intended for software, workload, bot, or automation access rather than ordinary human interactive use. ## Identity Record A record that describes, binds, or organizes information about an actor within a source or scope. Identity Record is deliberately narrower than bare `identity`; it is a record, not selfhood, not proof material, and not necessarily a login account. ## Identifier A value or reference used to distinguish or refer to something within a scope. Examples: username, email address, LDAP DN, OIDC subject, SAML NameID, DID, employee number, external source ID. ## Scoped Identifier An identifier whose meaning is intentionally limited to a relying party, sector, tenant, realm, application, namespace, or other scope. ## Credential Evidence or secret material used to prove control, entitlement, or a claim. Examples: password, passkey, certificate, hardware token, verifiable credential, recovery code, signed assertion. ## Claim A statement made by an issuer or source about an actor, account, identifier, relationship, or attribute. ## Authenticated Subject The protocol-level representation of an entity after an issuer or identity provider identifies it for a relying party. Examples: OIDC subject, SAML subject. ## Authorization Principal The entity considered by an authorization system when evaluating whether an action is allowed. ## Profile A presentation or attribute surface for an actor or account in a scope. Examples: public social profile, local application profile, directory profile. ## Persona A deliberate contextual presentation of an actor, often used to separate roles, audiences, privacy boundaries, or pseudonymous participation. ## Scope A boundary within which identifiers, meanings, relationships, accounts, policies, or lifecycle states are valid. Examples: tenant, realm, relying party, namespace, application, community, authorization domain. ## Tenant An administrative or isolation scope for a system, service, platform, or application. A tenant may be associated with an organization, customer, vendor, or community, but it is not automatically identical to any of them. ## Realm An issuer, security, or administrative namespace used by an identity system. After Keycloak and federation source review, Realm remains a **Scope specialization** for hard identity/admin boundaries (separate user namespaces, credentials, clients, IdPs). It is not interchangeable with Tenant or Organization. ## Organization A collective actor with operational, social, administrative, or structural continuity. Excludes: tenant, customer, and legal entity unless those meanings are modeled as separate relationships or specializations. ## Legal Entity An organization or other actor recognized by a legal system. ## Customer A commercial role played by an actor (usually an Organization, sometimes a Natural Person for individual subscriptions) that consumes services from a vendor. Customer is a relationship role, not a record type and not interchangeable with Tenant, Organization, Account, or Commercial Record. ## Vendor A commercial role played by an actor (usually an Organization) that provides services to customer actors. Vendor is a relationship role, not a tenant, realm, or organization synonym. ## Commercial Relationship A typed relationship connecting a vendor actor to a customer actor for a commercial or subscription purpose within a stated scope. May reference a Commercial Record for billing state. Does not imply membership, authorization, or identity equivalence. ## Commercial Record A record in a billing, CRM, or commerce system that tracks payment methods, subscriptions, invoices, contracts, or commercial contact details for an actor or tenant. Examples: Stripe Customer, Salesforce Account, subscription billing profile. Commercial Record is in the Record layer. It is not an Account (login), not an Organization actor, and not a Customer Account. Link it to Actor, Tenant, or Scope via Identifier binding or Commercial Relationship. ## Community A collective actor formed around participation, affiliation, identity, interest, moderation, or social interaction. ## Family Or Household A collective actor or relationship network involving family, guardian, dependent, household, or care relationships. This concept is privacy-sensitive and may have legal implications outside the canon's scope. ## Group A named collection of actors or accounts in a scope. Group membership may have authorization implications, but a group is not the same concept as a role, community, team, or organization. ## Role A named capability bundle, responsibility, or relationship label within a scope. Roles may be assigned through memberships or relationships, but role is not identical to group. ## Relationship A typed, scoped assertion connecting one actor, account, identifier, group, or other model element to another. Recommended fields: source, target, type, scope, evidence, issuer or source, confidence when relevant, lifecycle state, and authorization implications. ## Membership Relationship A relationship indicating that an actor or account belongs to, participates in, or is accepted by a collective actor or scope. ## Affiliation Relationship A relationship indicating association without necessarily implying membership, control, employment, or authorization. ## Following Relationship A directed social relationship where one actor subscribes to, follows, or observes another actor or profile. ## Representation Relationship A relationship where one actor acts or speaks on behalf of another actor within a scope. ## Delegation Relationship A relationship where one actor grants bounded authority to another actor. ## Administration Relationship A relationship where one actor has management authority over accounts, relationships, policies, or configuration in a scope. ## Trust Relationship A relationship where one actor, issuer, verifier, system, or scope relies on another for claims, identifiers, credentials, or decisions. ## Synonymity Assertion A scoped, evidenced assertion that two or more identifiers, records, accounts, profiles, or actors refer to the same target for a stated purpose. Recommended relation types: `same_as`, `probably_same_as`, `linked_to`, `represents`, `controls`, `acts_for`. Recommended strength bands: weak, medium, strong, authoritative. Synonymity assertions may be verified, inferred, revoked, privacy-limited, or source-specific. They do not require destructive merging of source records. Common sources: OIDC iss+sub account binding, SAML persistent NameID mapping, entity-resolution matches, operator verification, VC cryptographic proof, schema.org sameAs (weak by default). ## Evidence Source A source, document, event, issuer, import, observation, or verification process supporting a claim, relationship, or synonymity assertion. ## Lifecycle State The current state of a record, account, relationship, credential, claim, or assertion. Examples: proposed, active, suspended, revoked, expired, archived, deleted, superseded. Security event streams (SSF/CAEP/RISC) and VC status mechanisms are common Evidence Sources that trigger lifecycle transitions. ## Assurance Level Confidence metadata about identity proofing, authentication, or federation derived from sources such as NIST SP 800-63-4. Dimensions: - Identity Assurance Level (IAL): confidence that a subscriber is the claimed person. - Authenticator Assurance Level (AAL): confidence in authentication mechanism. - Federation Assurance Level (FAL): confidence in federation assertion protection. Assurance levels attach to bindings, credentials, and federation relationships; they do not replace authorization decisions. ## Relationship Tuple An authorization projection encoding a subject-relation-object fact in engines such as Zanzibar, OpenFGA, or Ory Keto. Relationship tuples are not canonical identity roots. They project from actors, accounts, memberships, and delegations into authorization domains. ## Pseudonymous Identifier An identifier designed to limit cross-scope correlation, aligned with privacy patterns such as OIDC pairwise subjects, tenant-local subjects, and GDPR pseudonymization with separately stored re-identification keys. ## Non-Canonical Convenience Term: User `User` may be used in prose when quoting or mapping external systems, but it should not be a canonical root concept. Resolve it to a specific canonical concept before using it in model definitions. ## Non-Canonical Convenience Term: Subscriber `Subscriber` (common in Auth0 B2B SaaS documentation) usually means the organization or party holding a subscription and tenant. Resolve to Organization + Customer Relationship role + Tenant Scope, or to Natural Person + Tenant for individual subscriptions. Do not model as Customer Account or Account. ## Non-Canonical Convenience Term: Customer Account Do not use `Customer Account` as a canonical term. Resolve by layer: - login/access → Account; - subscribing company → Organization + Customer Relationship role; - billing/CRM record → Commercial Record; - isolation boundary → Tenant.