From b9ae48b00c5f1221ee76d97a9aab5c8788edde1c Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 6 Sep 2026 01:39:09 +0200 Subject: [PATCH] Point identity and evidence mappings to current canon owners Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b --- INTENT.md | 4 +-- WORK-RECORDS.md | 2 ++ docs/canon-interface-card.yaml | 17 ++++++--- docs/canon-mapping.md | 22 ++++++++++-- docs/contracts.md | 4 +-- docs/identity-domain-naming-decision.md | 2 +- docs/interfaces/netkingdom-integration.md | 2 +- src/user_engine/ports.py | 2 +- workplans/ADHOC-2026-09-06.md | 44 +++++++++++++++++++++++ 9 files changed, 86 insertions(+), 13 deletions(-) create mode 100644 workplans/ADHOC-2026-09-06.md diff --git a/INTENT.md b/INTENT.md index c25e0ff..05f71ca 100644 --- a/INTENT.md +++ b/INTENT.md @@ -161,7 +161,7 @@ NetKingdom IAM, identity providers, provisioning sources, directories, authorization systems, security controls, event sinks, audit infrastructure, and optional UI surfaces while remaining useful in simple standalone deployments. -It may implement identity-canon entities when they are user-domain facts or +It may implement InfoTechCanon entities when they are user-domain facts or identity-context mappings. It should reference, map to, or consume adjacent canon entities when their source of truth belongs to NetKingdom infrastructure, security, access-control, governance, or organization systems. @@ -180,7 +180,7 @@ point by compilation or by local evaluation. - operators and tenant administrators managing scoped user populations; - agentic systems that need structured access to user preferences and profile context; -- domain services that need identity-canon aligned user, actor, principal, +- domain services that need InfoTechCanon aligned user, actor, principal, subject, tenant, team, membership, and evidence references without depending on technical IAM implementation details; - `access-engine`, as a PIP consumer of subject, membership, and diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index 29a7541..1542544 100644 --- a/WORK-RECORDS.md +++ b/WORK-RECORDS.md @@ -8,6 +8,7 @@ | Kind | ID | Status | Lane | Source | | --- | --- | --- | --- | --- | +| workplan | USER-WP-ADHOC-2026-09-06 | finished | — | workplans/ADHOC-2026-09-06.md | | workplan | USER-WP-0001 | finished | — | workplans/USER-WP-0001-preparation-and-interface-adoption.md | | workplan | USER-WP-0002 | finished | — | workplans/USER-WP-0002-isolated-mvp.md | | workplan | USER-WP-0003 | finished | — | workplans/USER-WP-0003-multi-tenancy.md | @@ -32,6 +33,7 @@ | workplan | USER-WP-0022 | finished | — | workplans/USER-WP-0022-public-registration-and-jit-application-profiles.md | | workplan | USER-WP-0023 | finished | — | workplans/USER-WP-0023-flex-auth-caller-identity.md | | workplan | USER-WP-0024 | finished | — | workplans/USER-WP-0024-security-layer-conformance.md | +| task | USER-WP-ADHOC-2026-09-06-T01 | done | — | workplans/ADHOC-2026-09-06.md | | task | USER-WP-0001-T1 | done | — | workplans/USER-WP-0001-preparation-and-interface-adoption.md | | task | USER-WP-0001-T2 | done | — | workplans/USER-WP-0001-preparation-and-interface-adoption.md | | task | USER-WP-0001-T3 | done | — | workplans/USER-WP-0001-preparation-and-interface-adoption.md | diff --git a/docs/canon-interface-card.yaml b/docs/canon-interface-card.yaml index 7d5a930..b71fab1 100644 --- a/docs/canon-interface-card.yaml +++ b/docs/canon-interface-card.yaml @@ -7,7 +7,7 @@ owner: codex updated: "2026-08-19" implements: - - identity-canon conceptual model as an implementation-facing domain facade + - InfoTechCanon identity/organization/access models as implementation-facing mappings - InfoTechCanon user-engine evaluation pack - small-saas user-management alignment surface @@ -35,7 +35,7 @@ consumes: - platform audit and event sinks owned_concepts: - user_record: User-engine local user record mapped to identity-canon User as a convenience term. + user_record: User-engine local user record mapped to InfoTechCanon User as a convenience term. account_record: Operational account state for a user-engine scope. external_identity_link: Source-specific issuer and subject link to a user record. profile_value: Scoped profile or preference value. @@ -86,7 +86,7 @@ required_identifiers: correlation_id: "operation-level audit and event correlation id" mapping_rules: - - Resolve source terms such as user, group, role, tenant, subject, and principal into identity-canon layers before exposing them as implementation concepts. + - Resolve source terms such as user, group, role, tenant, subject, and principal into InfoTechCanon identity, organization and access layers before exposing them as implementation concepts. - Keep account records, authenticated subjects, and authorization principals distinct even when they share issuer or subject identifiers. - Treat memberships as relationship facts that may produce grant-like access facts, not as final authorization decisions. - Preserve source system, scope, lifecycle state, and evidence reference whenever a relationship affects access, privacy, or lifecycle. @@ -113,7 +113,16 @@ source_of_truth: organization_authority: NetKingdom organization or directory systems known_deviations: - - User remains a local implementation class even though identity-canon treats user as a non-root convenience term; mappings must state whether it represents actor-facing profile holder, account owner, or local user record. + - User remains a local implementation class even though InfoTechCanon treats user as a non-root convenience term; mappings must state whether it represents actor-facing profile holder, account owner, or local user record. - Access Grant is currently a grant-like reference derived from memberships, not a durable authorization grant table. - Evidence Source references currently derive from local audit records unless an external evidence exporter is supplied. - AccessReview, Policy, Control, Exception, and lifecycle Task are references or gaps, not first-class owned records. + +federation_reference_review: + date: "2026-09-06" + project_task: CFED-WP-0001-T09 + mapping: docs/canon-mapping.md + canon_interfaces: + - info-tech-canon/infospace/interfaces/federation.yaml + - commerce-canon/infospace/interfaces/federation.yaml + disposition: Source references updated; runtime contracts and candidate conformance status unchanged. diff --git a/docs/canon-mapping.md b/docs/canon-mapping.md index 4000922..c69d936 100644 --- a/docs/canon-mapping.md +++ b/docs/canon-mapping.md @@ -4,12 +4,12 @@ Status: candidate Updated: 2026-06-05 This document maps current `user-engine` implementation concepts to -identity-canon and InfoTechCanon concepts. It is intentionally explicit about +InfoTechCanon identity, organization, access and evidence concepts. It is intentionally explicit about owned facts, consumed facts, references, and gaps. ## Mapping Stance -`identity-canon` treats `User` as a convenience term, not the root concept. +`InfoTechCanon` treats `User` as a convenience term, not the root concept. `user-engine` keeps the existing `User` implementation class for compatibility, but exposes canon-facing context through `identity_context` so consumers can see the distinct account, actor, subject, principal, tenant, membership, profile, @@ -101,3 +101,21 @@ They verify that: - cross-tenant identity context is denied without platform scope; - claims-enrichment context can be read without implying token issuance ownership. + +## Federation source references — 2026-09-06 + +Current owners: [itc-ident](../../info-tech-canon/infospace/models/identity/InfoTechCanonIdentityModel.md) +for identity, Scope and the User convenience mapping; +[itc-org](../../info-tech-canon/infospace/models/organization/InfoTechCanonOrganizationModel.md) +for actors and membership; [itc-access](../../info-tech-canon/infospace/models/access-control/InfoTechCanonAccessControlModel.md) +for Subject and Principal; and [itc-evid](../../info-tech-canon/infospace/models/evidence/InfoTechCanonEvidenceModel.md) +for Evidence assertions and addressable Evidence Source containers. +[CommerceCanon](../../commerce-canon/infospace/models/counterparty/CommerceCanonCounterpartyModel.md) +owns Customer, Vendor and Legal Entity semantics. + +This is a source-coordinate review under CFED-WP-0001-T09. Existing emitted +labels and scenario/test identifiers remain compatibility surfaces; the older +entity mappings above are not silently promoted to conformance with the newly +published draft models. Evidence references do not by themselves establish an +assertion/source distinction in every adapter. A full consumer adoption review +remains demand-driven. diff --git a/docs/contracts.md b/docs/contracts.md index 8571262..2721897 100644 --- a/docs/contracts.md +++ b/docs/contracts.md @@ -208,8 +208,8 @@ Every mutating service operation appends an audit record and outbox event with the same correlation id and resolved tenant. Authorization denials are audited without emitting outbox events. -Local audit records may be exported as identity-canon `Evidence Source` -references. Durable platform audit custody remains outside user-engine. +Local audit records may be exported as references to addressable Evidence Source +containers under InfoTechCanon `itc-evid`. Durable platform audit custody remains outside user-engine. ## Durable Store Contract diff --git a/docs/identity-domain-naming-decision.md b/docs/identity-domain-naming-decision.md index fa5d9bb..40d9096 100644 --- a/docs/identity-domain-naming-decision.md +++ b/docs/identity-domain-naming-decision.md @@ -43,7 +43,7 @@ Revisit the name when all of the following are true: - consumers primarily use the identity-context API rather than only user/profile APIs; - NetKingdom IAM, authorization, audit, and evidence adapters are stable; -- identity-canon mappings are validated by executable scenarios; +- InfoTechCanon mappings are validated by executable scenarios; - docs consistently describe the repo as an identity-domain facade and not as an identity provider; - downstream consumers would be misled by the old `user-engine` name. diff --git a/docs/interfaces/netkingdom-integration.md b/docs/interfaces/netkingdom-integration.md index 48cb571..7cded82 100644 --- a/docs/interfaces/netkingdom-integration.md +++ b/docs/interfaces/netkingdom-integration.md @@ -33,7 +33,7 @@ The user-engine boundary contract remains accepted in net-kingdom | `MembershipFactExporter` | outbound | Export user-engine-owned membership facts as read models for authorization systems. | | `EventOutbox` | outbound | Publish durable lifecycle/profile/catalog/membership events after commit. | | `AuditWriter` | local/outbound | Persist local audit and provide redacted summaries for platform audit sinks. | -| `EvidenceReferenceExporter` | outbound | Export local audit/review material as identity-canon evidence references without owning the platform audit system. | +| `EvidenceReferenceExporter` | outbound | Export local audit/review material as InfoTechCanon itc-evid evidence references without owning the platform audit system. | | `PolicyControlReferenceResolver` | outbound | Resolve policy, control, review, exception, or waiver references for identity-domain traces. | | `LifecycleTaskSink` | outbound | Create or link lifecycle, review, remediation, or integration-gap work in a task system. | | `SecretProvider` | inbound | Load runtime secrets through environment/local config in standalone mode and scoped secret providers in platform mode. | diff --git a/src/user_engine/ports.py b/src/user_engine/ports.py index faebf37..1814244 100644 --- a/src/user_engine/ports.py +++ b/src/user_engine/ports.py @@ -538,7 +538,7 @@ class AuditWriter(Protocol): class EvidenceReferenceExporter(Protocol): - """Export audit/review material as identity-canon evidence references.""" + """Export audit/review material as InfoTechCanon itc-evid evidence references.""" def export( self, audit_records: Iterable[AuditRecord] diff --git a/workplans/ADHOC-2026-09-06.md b/workplans/ADHOC-2026-09-06.md new file mode 100644 index 0000000..c6b632e --- /dev/null +++ b/workplans/ADHOC-2026-09-06.md @@ -0,0 +1,44 @@ +--- +id: USER-WP-ADHOC-2026-09-06 +type: workplan +title: "Update live canon federation references" +domain: communication +repo: user-engine +status: finished +owner: codex +created: "2026-09-06" +updated: "2026-09-06" +state_hub_workstream_id: "f62166a4-0bf4-5f9e-8b48-7b466091e226" +--- + +## Follow current canon source owners + +```task +id: USER-WP-ADHOC-2026-09-06-T01 +status: done +priority: medium +state_hub_task_id: "948a297b-9eab-5bac-aae9-acc32e1a5fc7" +``` + +Bounded source-reference correction authorized by CFED-WP-0001-T09. Preserve +historical workplans, evidence, UUIDs, runtime contracts and capability IDs. +Identity/evidence meanings now reference InfoTechCanon; the same renamed +repository is CommerceCanon for commercial semantics. + +Files reviewed: + +- `INTENT.md` +- `docs/contracts.md` +- `docs/canon-mapping.md` +- `docs/canon-interface-card.yaml` +- `docs/identity-domain-naming-decision.md` +- `docs/interfaces/netkingdom-integration.md` +- `src/user_engine/ports.py` + +Acceptance: no live obsolete source reference in these files, valid YAML/Python +where applicable, unchanged runtime behavior, and consolidated fleet evidence in +prj-canon-federation. This does not assert independent consumer adoption. + +Result: current source references corrected; syntax and targeted verification +passed. Consolidated proof is owned by CFED-WP-0001-T09. No new implementation +residual is introduced by this documentation/coordinate update.