tegwick
361c944325
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
217 lines
14 KiB
Markdown
217 lines
14 KiB
Markdown
---
|
||
id: itc-ident:IdentityModel
|
||
title: InfoTechCanon Identity Model
|
||
short_name: ITC-IDENT
|
||
type: domain-model
|
||
standard_family: InfoTechCanon
|
||
repository_context: info-tech-canon
|
||
recommended_path: models/identity/InfoTechCanonIdentityModel.md
|
||
status: draft
|
||
version: 0.1.0
|
||
canonical_owner: InfoTechCanonIdentityModel
|
||
namespace: itc-ident
|
||
classification: model
|
||
imports:
|
||
- InfoTechCanonCore
|
||
- InfoTechCanonOrganizationModel
|
||
- InfoTechCanonAccessControlModel
|
||
- InfoTechCanonEvidenceModel
|
||
owned_concepts:
|
||
- 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
|
||
created_at: 2026-09-05
|
||
updated_at: 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](../organization/InfoTechCanonOrganizationModel.md) | Actor; Person (Natural Person); Agent (Artificial Agent); Organization; Group; Role; Membership (Membership Relationship); Responsibility; Authority; Ownership |
|
||
| [ITC-ACCESS](../access-control/InfoTechCanonAccessControlModel.md) | Subject (Authenticated Subject); Principal (Authorization Principal); Relationship Tuple; ResourceScope; CredentialReference |
|
||
| [ITC-EVID](../evidence/InfoTechCanonEvidenceModel.md) | 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](../../../../prj-canon-federation/ledger/README.md) 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](boundary-review.md).
|