generated from coulomb/repo-seed
180 lines
6.1 KiB
Markdown
180 lines
6.1 KiB
Markdown
---
|
|
id: USER-WP-0007
|
|
type: workplan
|
|
title: "Identity Domain Canon Alignment"
|
|
domain: netkingdom
|
|
repo: user-engine
|
|
status: proposed
|
|
owner: codex
|
|
topic_slug: netkingdom
|
|
planning_priority: high
|
|
planning_order: 7
|
|
created: "2026-06-05"
|
|
updated: "2026-06-05"
|
|
depends_on:
|
|
- USER-WP-0006
|
|
---
|
|
|
|
# USER-WP-0007 - Identity Domain Canon Alignment
|
|
|
|
## Goal
|
|
|
|
Bring `user-engine` scope into alignment with its revised intent: make it the
|
|
NetKingdom identity-domain integration layer that exposes identity-canon aligned
|
|
user, account, actor, principal, subject, tenant, team, membership, profile,
|
|
lifecycle, and evidence context without absorbing identity provider,
|
|
credential, authorization, security-control, audit-platform, or organization
|
|
authority responsibilities.
|
|
|
|
## Scope Direction
|
|
|
|
`user-engine` should implement identity-canon entities when they are
|
|
user-domain facts or identity-context mappings. It should consume or reference
|
|
NetKingdom-owned entities when the source of truth belongs to IAM, security,
|
|
authorization, governance, audit, secrets, or organization systems.
|
|
|
|
The target integration question is:
|
|
|
|
```text
|
|
For this domain request, who is the actor, which user/account/principal/subject
|
|
context applies, which tenant/team/application scopes are relevant, which
|
|
identity-domain facts may be projected, and what evidence or lifecycle work
|
|
exists for that context?
|
|
```
|
|
|
|
## Non-Goals
|
|
|
|
- Do not turn `user-engine` into an identity provider.
|
|
- Do not implement passwords, passkeys, sessions, MFA, token issuance, or
|
|
credential lifecycle.
|
|
- Do not become the policy decision point or final authorization authority.
|
|
- Do not own NetKingdom security controls, runtime secrets, or durable platform
|
|
audit infrastructure.
|
|
- Do not become the full organization, HR, directory, or governance authority.
|
|
- Do not rename the repository as part of this workplan without a separate
|
|
naming decision record.
|
|
|
|
## Tasks
|
|
|
|
```task
|
|
id: USER-WP-0007-T1
|
|
status: todo
|
|
priority: high
|
|
```
|
|
|
|
Create a Canon Interface Card for `user-engine` that declares produced,
|
|
consumed, owned, mapped, and explicitly non-owned InfoTechCanon concepts. Cover
|
|
User, Account, ExternalIdentity, Actor, Principal, Subject, Tenant, Team,
|
|
Membership, Organization Role reference, AccessRole reference, Policy reference,
|
|
Control reference, Evidence reference, AccessReview reference, and lifecycle
|
|
work.
|
|
|
|
```task
|
|
id: USER-WP-0007-T2
|
|
status: todo
|
|
priority: high
|
|
```
|
|
|
|
Create entity and edge mapping exports for current domain objects. Map existing
|
|
models and service operations to canon concepts and relationships including
|
|
`member_of`, `belongs_to_tenant`, `authenticates_as`, `evaluated_as`,
|
|
`assigned_role`, `scoped_to`, `governed_by`, `implemented_by`,
|
|
`evidenced_by`, and `creates_task`.
|
|
|
|
```task
|
|
id: USER-WP-0007-T3
|
|
status: todo
|
|
priority: high
|
|
```
|
|
|
|
Define the first identity-context read model. It should resolve a verified
|
|
NetKingdom actor into domain-facing user, account, identity link, principal,
|
|
subject, tenant, team, membership, application, and profile projection context
|
|
without requiring consumers to know IAM provider details.
|
|
|
|
```task
|
|
id: USER-WP-0007-T4
|
|
status: todo
|
|
priority: high
|
|
```
|
|
|
|
Add explicit canon-facing distinctions where current code only has implicit
|
|
fields. In particular, distinguish User, Actor, Principal, Subject, Account,
|
|
ExternalIdentity, Organization Role reference, AccessRole reference,
|
|
Membership, and Grant or grant-like membership facts.
|
|
|
|
```task
|
|
id: USER-WP-0007-T5
|
|
status: todo
|
|
priority: medium
|
|
```
|
|
|
|
Add NetKingdom adapter contracts for identity-domain implementation. Preserve
|
|
the existing ports while adding or documenting adapters for IAM Profile claims,
|
|
authorization decisions and obligations, membership fact export, evidence or
|
|
audit reference export, policy/control references, and lifecycle task handoff.
|
|
|
|
```task
|
|
id: USER-WP-0007-T6
|
|
status: todo
|
|
priority: medium
|
|
```
|
|
|
|
Add evidence and review references without taking over governance ownership.
|
|
Identity-domain mutations, privileged memberships, delegated agent context,
|
|
break-glass context, and tenant admin grants should be traceable to audit,
|
|
review, approval, exception, remediation, or explicit evidence gaps.
|
|
|
|
```task
|
|
id: USER-WP-0007-T7
|
|
status: todo
|
|
priority: medium
|
|
```
|
|
|
|
Add small-SaaS canon conformance scenarios. Cover Ada Admin, Acme, Globex,
|
|
tenant isolation policy, namespace-per-tenant control, access review evidence,
|
|
tenant onboarding work, explicit grant scope, and integration gaps that become
|
|
tracked work rather than silent scope drift.
|
|
|
|
```task
|
|
id: USER-WP-0007-T8
|
|
status: todo
|
|
priority: low
|
|
```
|
|
|
|
Create a naming decision record after the alignment artifacts exist. Compare
|
|
keeping `user-engine` with renaming to `identity-engine`,
|
|
`identity-domain-engine`, or another name. Decide based on actual implemented
|
|
scope, consumer expectations, and risk of implying ownership of full IAM or
|
|
organization responsibilities.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- `INTENT.md`, `SCOPE.md`, and public docs consistently describe
|
|
`user-engine` as the NetKingdom identity-domain integration layer.
|
|
- A completed Canon Interface Card exists for `user-engine`.
|
|
- Entity and edge mapping exports cover current user-engine models and mark
|
|
gaps explicitly.
|
|
- Consumers can ask for identity-domain context without knowing the concrete IAM
|
|
provider, authorization system, audit sink, or security-control
|
|
implementation.
|
|
- User, Actor, Principal, Subject, Account, ExternalIdentity, Tenant, Team,
|
|
Membership, Organization Role reference, AccessRole reference, Grant or
|
|
grant-like fact, Policy reference, Control reference, Evidence reference, and
|
|
AccessReview reference are distinct or explicitly mapped gaps.
|
|
- Tenant-scoped privileged access can be traced to scope, decision, policy or
|
|
control reference, and evidence or evidence-gap record.
|
|
- Small-SaaS conformance scenarios pass or produce explicit, owned gap records.
|
|
- The repository name remains unchanged unless a separate naming decision is
|
|
accepted.
|
|
|
|
## Expected Outputs
|
|
|
|
- `docs/canon-interface-card.yaml`
|
|
- `docs/canon-mapping.md` or generated equivalent
|
|
- identity-context read model and tests
|
|
- NetKingdom adapter contract updates
|
|
- small-SaaS canon conformance tests
|
|
- evidence-gap and lifecycle task examples
|
|
- naming decision record
|