identity-canon/canon/CanonicalGlossary.md

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.