info-tech-canon/infospace/models/identity/InfoTechCanonIdentityModel.md

id	title	short_name	type	standard_family	repository_context	recommended_path	status	version	canonical_owner	namespace	classification	imports	owned_concepts	created_at	updated_at
itc-ident:IdentityModel	InfoTechCanon Identity Model	ITC-IDENT	domain-model	InfoTechCanon	info-tech-canon	models/identity/InfoTechCanonIdentityModel.md	draft	0.1.0	InfoTechCanonIdentityModel	itc-ident	model	InfoTechCanonCore InfoTechCanonOrganizationModel InfoTechCanonAccessControlModel InfoTechCanonEvidenceModel	Account Service Account Identity Record Identifier Scoped Identifier Credential Claim Profile Persona Scope Tenant Realm Relationship Affiliation Relationship Following Relationship Representation Relationship Delegation Relationship Administration Relationship Trust Relationship Synonymity Assertion Lifecycle State Assurance Level Pseudonymous Identifier	2026-09-05	2026-09-05

InfoTechCanon Identity Model

Draft 0.1.0 implements accepted CUST-ADR-006 decision 4 and R1/R2/R4. It describes identity records, contextual identifiers and actor-linking relationships, while importing actor, authorization and evidence semantics.

1. Imported boundary

Owner	Imported concepts and donor aliases
ITC-ORG	Actor; Person (Natural Person); Agent (Artificial Agent); Organization; Group; Role; Membership (Membership Relationship); Responsibility; Authority; Ownership
ITC-ACCESS	Subject (Authenticated Subject); Principal (Authorization Principal); Relationship Tuple; ResourceScope; CredentialReference
ITC-EVID	Evidence; Evidence Source; Evidence strength

Aliases map donor terminology to upstream concepts; they do not copy the donor's competing definitions. In particular Subject follows the Access Control model, not an identity-owned protocol definition. Organization and its social extensions remain upstream. Community/Household publication is T12; Family is a separate seed under T13 and is not treated as a collective actor here.

Delegation moves from Organization's live definition into the already accepted identity ownership assignment, with Organization retaining an import at its old anchor. Identifier similarly moves from Information Space's live generic definition to identity; its artifact-specific conventions stay in Information Space. The boundary review records why these are transfers, not new ownership decisions. Draft registration is not stable promotion or consumer adoption.

2. Owned concepts

2.1 Account

Account — A record through which an actor obtains or maintains access to a system within a scope. A Service Account is one specialization. An Account is not the actor, a credential, an authorization principal, or a billing/CRM record.

2.2 Service Account

Service Account — An Account intended for software, workload, bot, or automation access rather than ordinary human interactive use. The account and the Agent using it remain separate.

2.3 Identity Record

Identity Record — A record that describes, binds, or organizes information about an actor within a source or scope. It is not selfhood, proof material, or necessarily a login Account.

2.4 Identifier

Identifier — A value or reference used to distinguish or refer to something within a Scope. Record the namespace or issuer context needed to interpret it. Equal values in different scopes do not establish equivalence. Artifact identifiers can additionally require stability, namespace uniqueness, machine readability and version awareness through Information Space conventions.

2.5 Scoped Identifier

Scoped Identifier — An Identifier whose meaning is intentionally limited to a relying party, sector, tenant, realm, application, namespace, or other scope. Explicit scoping does not make the identified record a different Actor.

2.6 Credential

Credential — Proof material or a mechanism used to demonstrate control, entitlement, or a Claim, such as an authenticator, certificate, or signed assertion. Evidence about verification and its addressable source are imported from ITC-EVID; a secret is not automatically an evidence assertion. A CredentialReference remains an Access Control reference to this concept. Payment instrument references and commercial mandates belong to CommerceCanon, not to login credential semantics.

2.7 Claim

Claim — A statement made by an issuer or source about an actor, account, identifier, relationship, or attribute. A Claim is not necessarily verified. When captured as Evidence for a stated interest, retain the distinct assertion and Evidence Source; the identity statement and its assessed support remain distinguishable.

2.8 Profile

Profile — Descriptive attributes or presentation for an Actor or Account in a Scope. This is an identity profile, distinct from a canon application profile and from Observability’s runtime performance Profile.

2.9 Persona

Persona — A deliberate contextual presentation of an Actor, used to separate roles, audiences, privacy boundaries, or pseudonymous participation. Different personas do not by themselves prove different actors.

2.10 Scope

Scope — A boundary within which identifiers, meanings, relationships, accounts, policies, or lifecycle states are valid. Tenant and Realm specialize Scope; Access Control retains the narrower ResourceScope. Namespace remains an Information Space naming mechanism using scoping.

2.11 Tenant

Tenant — An administrative or isolation Scope for a system, service, platform, or application. It may be associated with an Organization or commercial party, but is not identical to either. Isolation must be implemented downstream; naming a tenant does not enforce it.

2.12 Realm

Realm — An issuer, security, or administrative namespace used by an identity system, modeled as a Scope specialization. It represents an identity/admin boundary and is not interchangeable with Tenant or Organization.

2.13 Relationship

Relationship — A typed, scoped assertion connecting an actor, account, identifier, group, or other identity-model element to another. This is the identity actor-linking taxonomy, not ownership of every graph edge or Core RelationshipDefinition. Record endpoints, type, scope, provenance, lifecycle and relevant evidence. Imported Membership and Ownership concepts must not acquire duplicate definitions under identity-specific spellings.

2.14 Affiliation Relationship

Affiliation Relationship — An association without necessarily implying membership, control, employment, or authorization. Do not infer an imported Membership merely from affiliation.

2.15 Following Relationship

Following Relationship — A directed social relationship where one actor follows, subscribes to, or observes another actor or profile. Social following is not a commercial subscription or authorization grant.

2.16 Representation Relationship

Representation Relationship — A relationship in which one actor acts or speaks on behalf of another within a scope. Representation does not by itself establish how authority was granted; reference Delegation Relationship when that is the basis.

2.17 Delegation Relationship

Delegation Relationship — A relationship in which an actor transfers or grants responsibility or authority to another actor within defined limits. This consolidates the donor’s bounded-authority definition with the existing Organization §10.18 definition. Delegation is its compatibility name, not a second owned concept. Actor, Responsibility and Authority are imported from Organization. Record delegator, delegate, delegated scope/authority or responsibility, validity interval, revocability and constraints. A delegation assertion does not itself grant an authorization-engine permission.

2.18 Administration Relationship

Administration Relationship — A relationship in which an actor has management authority over accounts, relationships, policies, or configuration in a Scope. Record its basis and limits; management status does not silently grant every possible access permission.

2.19 Trust Relationship

Trust Relationship — A relationship in which an actor, issuer, verifier, system, or Scope relies on another for claims, identifiers, credentials, or decisions. State the purpose and basis of reliance using imported Evidence and Evidence Source. Commercial reliance may name CommerceCanon’s Counterparty Assurance Gradient when available; identity does not define that gradient.

2.20 Synonymity Assertion

Synonymity Assertion — A scoped, evidenced and revocable assertion that identifiers, records, accounts, profiles, or actors refer to the same target for a stated purpose. Retain method, confidence, provenance, privacy constraints and lifecycle. A weak match is not a verified link or a destructive merge. Representation, control and acts-for relationships are not equivalence merely because a donor system stores them in the same linking table.

2.21 Lifecycle State

Lifecycle State — The current state of a record, account, relationship, credential, claim, or assertion. A record’s type or profile defines its applicable states and transitions; illustrative states include proposed, active, suspended, revoked, expired and superseded. Evidence may support a transition without automatically authorizing it.

2.22 Assurance Level

Assurance Level — Confidence metadata for a specified identity-proofing, authentication, or federation dimension under a named scheme and version. Keep those dimensions distinct, attach assessments to the relevant binding, credential or federation relationship, and record the supporting Evidence. A level is not a global account trust score or an authorization decision. Governance AssuranceCase/AssuranceConclusion and general Evidence strength remain separately owned.

2.23 Pseudonymous Identifier

Pseudonymous Identifier — An Identifier designed to limit correlation across contexts. Record its permitted scope and linking policy; pseudonymity does not itself guarantee anonymity. Any re-identification relationship remains separately controlled and evidenced.

3. Convenience terms

User and Subscriber are mapped convenience terms, not canonical root concepts. Resolve User to the relevant Actor, Account, Subject, Principal or Profile. Resolve Subscriber according to context: a commercial subscription holder uses CommerceCanon roles and relationships; an identity-system usage may refer to an Account or Person; social following uses Following Relationship. Do not force these meanings into a single record type or infer a commercial commitment.

4. Carried design principles

P1 uses imported Actor as the participation root; Service Account is a record, not an actor. P2 separates Person, Account, Identity Record, Profile, Credential, Subject and Principal. P3 keeps Scope explicit. P4 keeps collectives distinct, using imported Organization concepts and the accepted Family/Household split. P5 models different relationships explicitly while respecting their owners. P6 keeps authorization projections separate from identity records. P7 makes synonymity a scoped, evidenced and revocable assertion. P8 separates captured Evidence from its addressable Evidence Source. P9 maps product terms to orthogonal concepts rather than adopting product labels. P10 tests concrete scenarios without claiming that the original mixed corpus has already been migrated. P11 leaves implementations downstream. P12 separates proofing, authentication and federation assurance dimensions. P13 prefers non-destructive linking; weak matches require review and never imply silent merges. Commerce P14/P15 remain with CFED T06.

5. Worked boundary cases

Case	Representation and acceptance constraint
One employee has two application logins	One imported Person may control two Accounts, each with scoped Identifiers. Do not infer identity equivalence from equal usernames.
A workload uses a service login	Imported Agent and Service Account remain separate; authentication yields an imported Subject/Principal projection.
A vendor administers a customer's tenant	Separate imported Organizations, Tenant and Administration Relationship. Commercial reliance is a CommerceCanon relationship, not implied membership.
An operator delegates bounded authority to an agent	One Delegation Relationship uses imported Actors/Authority and explicit limits. Organization imports this same relation; authorization enforcement remains with Access Control.
Two records are a probabilistic match	Preserve both records; capture a revocable Synonymity Assertion with method, purpose and evidence. A match does not authorize a merge.
One actor has two pseudonymous personas	Retain separate Personas and scoped identifiers; cross-context linking requires its own evidenced, privacy-constrained assertion.
A credential expires	Its lifecycle change does not erase the Person or necessarily close every Account.
A group membership is projected into an access tuple	Import Membership and Relationship Tuple; identity owns neither definition.

6. Provenance

The federation ledger pins the donor glossary at 4bb474970b73d500da03b6482e84e6c256146b79. All 23 identity-owned concepts are represented here; User/Subscriber are convenience mappings. Donor P1–P13 are adapted to accepted boundaries, rather than copying their obsolete Family-as-actor, Service-Account-as-actor or source/evidence conflations.

Native INFO-WP-0021 implements CFED-WP-0001-T05. T06 owns the commerce model; T07 owns corpus distribution and T08 interface cards. Original seeds and source research remain unchanged. See boundary review.