diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index 6868459..0c0b83e 100644 --- a/WORK-RECORDS.md +++ b/WORK-RECORDS.md @@ -17,6 +17,7 @@ | workplan | HUB-WP-0007 | finished | — | workplans/HUB-WP-0007-workload-projection-transport.md | | workplan | HUB-WP-0008 | finished | — | workplans/HUB-WP-0008-legacy-message-identity-reconciliation.md | | workplan | HUB-WP-0009 | proposed | — | workplans/HUB-WP-0009-extension-conformance-gaps.md | +| workplan | HUB-WP-0012 | proposed | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md | | task | HUB-WP-0001-T01 | done | — | workplans/HUB-WP-0001-statehub-bootstrap.md | | task | HUB-WP-0001-T02 | done | — | workplans/HUB-WP-0001-statehub-bootstrap.md | | task | HUB-WP-0001-T03 | done | — | workplans/HUB-WP-0001-statehub-bootstrap.md | @@ -61,3 +62,11 @@ | task | HUB-WP-0009-T02 | todo | — | workplans/HUB-WP-0009-extension-conformance-gaps.md | | task | HUB-WP-0009-T03 | todo | — | workplans/HUB-WP-0009-extension-conformance-gaps.md | | task | HUB-WP-0009-T04 | todo | — | workplans/HUB-WP-0009-extension-conformance-gaps.md | +| task | HUB-WP-0012-T01 | todo | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md | +| task | HUB-WP-0012-T02 | todo | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md | +| task | HUB-WP-0012-T03 | todo | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md | +| task | HUB-WP-0012-T04 | todo | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md | +| task | HUB-WP-0012-T05 | todo | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md | +| task | HUB-WP-0012-T06 | todo | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md | +| task | HUB-WP-0012-T07 | wait | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md | +| task | HUB-WP-0012-T08 | todo | — | workplans/HUB-WP-0012-netkingdom-platform-root-access.md | diff --git a/docs/netkingdom-access-blueprint.md b/docs/netkingdom-access-blueprint.md new file mode 100644 index 0000000..5ba6311 --- /dev/null +++ b/docs/netkingdom-access-blueprint.md @@ -0,0 +1,232 @@ +# Hub Core and extension access through NetKingdom + +Status: proposed implementation blueprint, 2026-09-28. Owner: `hub-core`. +Execution record: [HUB-WP-0012](../workplans/HUB-WP-0012-netkingdom-platform-root-access.md). +Requested outcome: the person signing in as `platform-root` can access and +administer the whole platform, including Hub Core, its extensions, and Railiance. +Other human users are denied initially. Public exposure follows proven access +enforcement. Fine-grained delegation is a later phase of the same workplan. + +## Findings and evidence boundary + +This is a source/configuration review plus read-only runtime observation, not +an authenticated platform-root acceptance test. No account, token, role, +policy, public listener, or production workload was changed. + +| Boundary | Observed state on 2026-09-28 | Consequence | +| --- | --- | --- | +| Hub Core | `runtime/app.py` mounts `ports.py` without a global authorization dependency; native registration, messaging, events and generic projections lack a verified subject/tenant context | Enforce access in the service and SDK, not only at Ingress | +| Compatibility API | `runtime/compat.py::_protected` accepts a shared configured bearer or an imported consumer key; no resource/tenant decision follows | Replace broad bearer authority with authenticated principal plus action authorization | +| MCP | Separate runtime/transport and reusable host wrapper | Inventory every tool and carry caller identity to the same protected API; no server-wide root token | +| Inbox pilot | Snapshot GET reader uses the shared token and literal `state-hub` recipient | Keep private; caller migration remains HUB-WP-0011, not a completed retirement slice | +| Extension conformance | HUB-WP-0009 finished C2/C7/C9/C10; its explicit tenant-isolation gap has no implementation | This workplan owns the new security profile; 0.1 conformance is insufficient for exposure | +| Identity | Live issuer discovery at `https://kc.coulomb.social` advertises S256, authorization code and client credentials; KeyCape, Authelia, LLDAP and identity-provisioner Deployments Ready | Reuse the issuer; no second identity database or new IdP | +| User and tenant management | User Engine and Tenant Engine Deployments Ready; USER-WP-0030 and NK-WP-0038 finished | Reuse account lifecycle and tenant authority; readiness does not prove this root account's effective grants | +| Policy | Six service-specific flex-auth Deployments Ready; none for Hub Core | Register a protected system and owner-managed policy deployment; don't borrow another consumer's PDP/credentials | +| Hosting | Core Hub legacy/candidate/publisher Ready; revision 28 has Ingress off | Keep private until the new admission gate; the earlier public grant alone does not satisfy this request | +| Current external blockers | Public host presents Traefik default certificate; publisher accepts 113/123 with nine private-source errors and an identity-canon registry mismatch | Existing RAPPCOREHUB-WP-0002/0003 retain these operational obligations | + +Source findings use the current checkout. Live hub image remains the September 5 +pin, so later source conformance changes are not claimed deployed. The root +account's immutable subject, effective memberships, MFA and revocation behavior +still require an attended, non-secret acceptance receipt. + +## Authority and request path + +```mermaid +flowchart TD + Human[Human: platform-root] --> Login[KeyCape OIDC login] + Login --> Client[Hub browser session or CLI] + Users[User Engine: account and membership lifecycle] --> Facts[Verified account and tenant facts] + Tenants[Tenant Engine: tenant lifecycle and capability roles] --> Facts + Client --> Hub[Hub Core API: authenticate and enforce] + Workload[Named service or agent identity] --> Hub + Facts --> Policy[flex-auth: action and resource decision] + Hub --> Policy + Hub --> Extension[Extension API: authenticate and enforce] + Extension --> Policy + Extension --> Owner[Railiance or domain owner: execute and enforce] + Owner --> Audit[Durable audit evidence] + Hub --> Audit +``` + +KeyCape owns authentication and signed IAM claims. User Engine owns account, +application profile and membership lifecycle. Tenant Engine owns tenant state +and capability roles. NetKingdom owns the IAM profile and identity integration. +`flex-auth` owns decisions; the announced `access-engine` rename changes a repo +coordinate, not current runtime names or audiences (NK-WP-0039). + +Hub Core and every extension enforce decisions locally. Domain services retain +their data, commands and approvals. Railiance retains infrastructure execution; +ops-warden retains SSH certificate issuance; approval-engine retains durable +approval lifecycle; OpenBao/platform owners retain credential custody. Hub Core +does not become a privileged Kubernetes or OpenBao proxy merely by hosting UI. + +## M1: full platform-root access + +Bind the existing platform-root account by verified `(issuer, subject)`, resolved +through its owning identity/account records. A username or email is only a +display/lookup hint, never the privilege check. Do not fabricate a subject UUID, +auto-promote the first login, or grant every `platform-operator` root access. +User Engine currently uses `platform-operator` for some administrative gates; +T02 must map the specific root account's entitlement into those existing policy +vocabularies rather than assume a universal `platform-root` role already exists. + +M1 grants that principal all registered platform actions and resources through +each service's normal enforcement path, including Hub Core registry, messaging, +events, projections, work/repository operations via owners, extension surfaces, +tenant administration, and Railiance administration. Where full administration +requires crossing tenant boundaries, record an explicit platform-root grant +and audit both actor tenant and target tenant. Root remains `tenant:platform`; +it does not impersonate a tenant member. Tenant admins and ordinary users gain +no platform access in M1. Workloads retain only their individually registered +service/agent permissions and cannot inherit the human grant. + +Use a versioned, owner-reviewed action/resource catalog and entitlement, not a +hardcoded middleware bypass. New actions require catalog/policy review before +they become routable. Fine-grained human roles are deferred, but signature +validation, deny-by-default, tenant attribution and audit are M1 requirements. +Full access does not waive existing confirmations, approval obligations, +single-writer controls, secret non-disclosure, or emergency custody rules. + +The estate access matrix must enumerate every active platform service and +management surface from owner/Fabric inventories. Seed it with Hub Core, +ops-hub, repo-manager, activity-core, User/Tenant Engine, identity administration, +policy/approval/audit surfaces, Forgejo, OpenBao/secrets operations, and +Railiance Kubernetes, deployment/GitOps, SSH and observability. Each row names +owner, resource/realm, audience, enforcement point, grant, safe test, and receipt. +Existing native/SSH/attended paths may satisfy a row; a generic hub token may +not. M1 is not complete while any inventoried platform surface is inaccessible +or untested. Non-hub services need integration, not reclassification as hubs. + +## Authentication and session contract + +Use accepted [IAM Profile v0.3](../../net-kingdom/canon/standards/iam-profile_v0.3.md). +The browser uses Authorization Code + PKCE S256 through a confidential session +backend with exact registered redirects, state/nonce, Secure HttpOnly cookies, +CSRF protection and logout. Store tokens server-side, not browser local storage. +CLI/MCP clients use an issuer-supported flow and their own audience-bound +credentials; do not assume device flow or token exchange exists without proof. +The OAuth design follows [RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html). + +The API validates access-token type, issuer, audience, allowed algorithm, +signature, key rotation, expiry/not-before and required IAM claims. ID tokens +are not API credentials. Missing/invalid authentication returns 401; verified +but disallowed access returns 403; unavailable authorization returns a bounded +503 without executing work. Resolve trusted resource/tenant facts on the server; +ignore user-supplied subject, role, tenant headers and purported verified flags. + +Platform-root requires AAL2 or stronger per IAM v0.3 and NK-ADR-0016; an ordinary +SSO session does not establish that. Reuse the accepted enrollment/recovery +journeys and attest the privileged login. NK-WP-0042's per-request step-up and +IAM v0.4 are proposed, not available guarantees. M1 can use the existing +per-client privileged MFA path only after its usability/return journey is +accepted; otherwise remain private and record that blocker. + +T02 fixes measurable token/session lifetimes, assurance freshness and maximum +grant-revocation delay. Proposed upper bound: five minutes for ordinary root +access; privileged mutations recheck current root entitlement and tenant state +at execution and fail closed when unavailable. Logout invalidates the local +session immediately; expired or revoked authority cannot survive refresh. +Use authoritative owner APIs for high-stakes tenant capability facts; +`tenant_roles` in a token is only a cache. Test user suspension, grant removal, +tenant suspension and issuer/policy outages, not just successful sign-in. + +## Authorization, forwarding and extension contract + +Every request carries server-established actor, calling workload, target +tenant, action, resource, assurance and correlation identity. The service +authenticates to flex-auth using an admitted workload identity separately from +the end user's identity. Caller TokenReview alone must not authorize arbitrary +claims asserted by that caller. Adopt the current fact-provenance and binding +contracts (FLEX-WP-0025, FLEX-WP-0017). + +Verify the decision's request binding, action/resource/tenant, validity, +policy version, obligations and authenticated origin. Require a signed decision +and trusted rotating verification keys per FLEX-WP-0024, or an explicitly +reviewed equivalent authenticated channel. An unsigned development decision is +not sufficient for public M1. Signing code being finished does not prove a +production signing-key custody lane exists; owner delivery is a T03 gate. +Audit allow/deny/error with actor, caller, tenant, action/resource, policy and +decision IDs, correlation and outcome; never tokens or message bodies. Required +audit failure prevents privileged mutation; bounded durable buffering must be +specified rather than silently dropping evidence. + +Expose one reusable enforcement/context seam for embedded routers, native +`/ports`, `/api/v2`, aliases, docs/catalogs, projection APIs, browser and MCP. +Only minimal liveness and the exact login/callback mechanics may be unauthenticated; +detailed readiness is internal. Test direct Service requests as well as Ingress. +Legacy keys get explicit private, bounded migration lanes with named owners; +they must not become a public bypass or be distributed to extensions. + +An extension manifest declares protected-system identity, token audience, +action/resource namespaces, tenant behavior and required security-contract +version. Extensions validate their own audience and enforce their own policy; +Hub Core cannot forward a bearer to an unrelated audience. Use only a proven +issuer delegation/exchange mechanism, or a reviewed authenticated workload call +with integrity-bound end-user delegation. If neither exists, use a separate +client login and leave delegation unsupported. Never relay root's bearer as a +generic backend credential. Service-initiated events bind producer/address to +the authenticated workload; payload `sender` is not authority. + +Version the security profile and extend conformance beyond HUB-WP-0009. +Cover list/filter/detail, exports, caches, pagination, broadcasts, aliases, +streaming/MCP and event replay; no cross-tenant existence/count leak. Classify +legacy unlabelled records explicitly as platform-owned or quarantine them; +never infer their tenant from the current viewer. Platform-root may administer +them through its explicit platform grant. Non-root multi-tenant admission waits +for Phase 2 data migration and isolation tests. + +## Retirement integration and sequencing + +| Existing owner record | Relationship to this work | +| --- | --- | +| HUB-WP-0004/0005, CORE-WP-0010 | Runtime selection/absorption already decided; implement here, retain Core Hub rollback privately; no new feature lane in Core Hub | +| HUB-WP-0009 | Existing contract checks stay finished; this work owns the missing identity/tenant conformance profile | +| HUB-WP-0011 | Reuse the new caller/context seam for T02; inbox freshness, retention, recipient/alias semantics and reader switch stay there | +| STATE-WP-0079 | Authentication does not close its 425-item disposition, single-writer, parity, metering or retirement gates; apply the security gate per slice | +| RMGR-WP-0001/0002/0003 | Git/file authority stays in Repo Manager; Hub Core views and invokes governed owner APIs | +| OPS-WP-0003; ACTIVITY-WP-0029 | Existing extension and event/schedule alignment finished; add security conformance/caller migration without reopening completed tasks | +| FIN-WP-0003; RAIL-FAB-WP-0028 | Fabric authority stays specialized; hosted Fabric is blocked independently; integrate the available owner surface and report missing runtime evidence | +| RAPPCOREHUB-WP-0002/0003/0004 | Packaging/exposure, publisher credential gate and completed private inbox pilot retain their owners | +| NK-WP-0038/0039/0042; USER-WP-0030; TEN-WP-0012 | Reuse delivered identity/admin behavior; respect pending coordinate, step-up and tenant conformance work rather than claim them complete | + +Implement shared contracts and platform-root access privately first. Exercise +one extension (ops-hub), actual workload callers and Railiance owner paths, then +complete the platform access matrix. Gate each State Hub reader/writer move on +the same identity checks plus that slice's existing data/freshness gates. +Do not add permanent authentication/tenant authority to retiring State Hub. + +Public enablement is a separate final gate under RAPPCOREHUB-WP-0002: authenticated +root success, ordinary-user/anonymous denial, direct-path denial, MFA, revocation, +policy failure, audit, all published route/tool coverage, current image pins, +TLS issuance and consumer tests, then explicit exposure approval. Fix release +configuration so routine upgrades preserve the approved exposure mode while +new installations default private. Do not expose the legacy rollback service. +Rollback retracts public access before restoring any image lacking enforcement; +it never restores an anonymously reachable older runtime. No full historical +Helm rollback that silently revives the old public configuration. + +## Later phase retained in the same plan + +After M1, define tenant-admin and ordinary-user grants, delegated agents, +per-extension/action permissions, recipient ACLs and tenant-scoped storage, +queries, caches and retention. Preserve the root entitlement as an explicit +policy grant. Phase 2 is open work, not a prerequisite for proving the coarse +root-only model, and must not be silently dropped when M1 closes. + +## Source map + +- `hub-core/hub_core/runtime/{app,ports,compat,config,inbox_projection}.py`, + `hub_core/mcp/server.py`, `docs/runtime.md`, `docs/conformance.md`. +- NetKingdom `docs/platform-identity-security-architecture.md`, accepted IAM + v0.3, `docs/adr/ADR-0016-mfa-user-preference-and-workload-step-up.md`. +- User Engine `wiki/ArchitectureBlueprint.md`, `docs/development.md`; + flex-auth `docs/iam-profile-consumption.md`, decision binding/signature and + inbound caller-auth contracts. The older consumption doc's v0.2 reference + does not supersede accepted additive v0.3. +- Retirement project `architecture/hub-extension-architecture_v0.1.md`, + `architecture/child-workplan-map_v0.1.md`, and owner workplans in the table. + Historical map statuses are not treated as current delivery evidence. +- Runtime checks: deployment readiness listing, issuer discovery, and + `rapp-core-hub/docs/evidence/loose-end-review-20260928.md`. diff --git a/workplans/HUB-WP-0009-extension-conformance-gaps.md b/workplans/HUB-WP-0009-extension-conformance-gaps.md index ed6b29a..9ed67c2 100644 --- a/workplans/HUB-WP-0009-extension-conformance-gaps.md +++ b/workplans/HUB-WP-0009-extension-conformance-gaps.md @@ -133,3 +133,8 @@ profile, unchanged from the original scoping note. scope: the 0.1 runtime still has no tenant identity/authorization context, as noted in `docs/conformance.md`; no owner record exists to link because there is no implementation to attribute one to. + +2026-09-28 follow-up: the newly requested `HUB-WP-0012` now owns the +identity/tenant enforcement and extension security profile, including Phase 2 +isolation. This supplies the missing residual owner without claiming that +the 0.1 profile already implements tenant isolation. diff --git a/workplans/HUB-WP-0011-statehub-inbox-freshness-and-cutover.md b/workplans/HUB-WP-0011-statehub-inbox-freshness-and-cutover.md index a0b9191..3b36a49 100644 --- a/workplans/HUB-WP-0011-statehub-inbox-freshness-and-cutover.md +++ b/workplans/HUB-WP-0011-statehub-inbox-freshness-and-cutover.md @@ -66,6 +66,12 @@ and thread/read/archive semantics for the selected reader. The existing pilot supports only one literal agent and exact sender filters. Never distribute the operator token as an application credential. +2026-09-28 integration dependency: `HUB-WP-0012-T02` through `T05` own the +shared NetKingdom identity, policy and workload-caller contract. Reuse that +contract here; this task retains inbox-specific recipient/alias semantics. +The root-only human milestone does not authorize an automated reader as root +or close the freshness and reader-switch tasks. + ## Execute one reviewed client switch ```task diff --git a/workplans/HUB-WP-0012-netkingdom-platform-root-access.md b/workplans/HUB-WP-0012-netkingdom-platform-root-access.md new file mode 100644 index 0000000..5df6b7a --- /dev/null +++ b/workplans/HUB-WP-0012-netkingdom-platform-root-access.md @@ -0,0 +1,238 @@ +--- +id: HUB-WP-0012 +type: workplan +title: "NetKingdom identity and tenant integration: platform-root first" +domain: infotech +repo: hub-core +status: proposed +flavor: implementation +owner: codex +topic_slug: infotech +created: "2026-09-28" +updated: "2026-09-28" +related: + - HUB-WP-0009 + - HUB-WP-0011 + - STATE-WP-0079 + - CORE-WP-0010 + - RAPPCOREHUB-WP-0002 + - RAPPCOREHUB-WP-0003 + - NK-WP-0038 + - NK-WP-0039 + - NK-WP-0042 + - USER-WP-0030 + - TEN-WP-0012 + - FLEX-WP-0024 + - FLEX-WP-0025 + - SHR-WP-0001 +state_hub_workstream_id: "e61ce290-c5ec-516c-8589-ef9a55cf3aa3" +--- + +# NetKingdom integration, platform-root first + +## Outcome and boundaries + +The existing platform-root login receives full Hub Core, extension and platform +access, including Railiance, through verified NetKingdom identity and the +owners' enforcement paths. Other human users are denied initially. Public +exposure waits for access-control evidence and a separate approved rollout. + +[Architecture blueprint](../docs/netkingdom-access-blueprint.md) defines the +contract and reviewed baseline. This is the single new integration workplan; +existing retirement and rollout plans retain their tasks. Core Hub receives no +new product feature work. This planning session does not implement or activate +grants, enroll factors, deploy policies, expose services or retire State Hub. + +Status is proposed because cross-owner policy, root identity binding and live +acceptance are not yet reviewed. The user has selected the root-first scope; +there is no need to reopen that product decision. Dependencies below are +per-task sequencing, not a blanket wait for every related workplan to finish. + +## T01 — Freeze the integration contract and platform coverage matrix + +```task +id: HUB-WP-0012-T01 +status: todo +priority: high +state_hub_task_id: "204f4fb0-e240-5558-8790-5985517b85e0" +``` + +Owner: hub-core; contract reviewers: NetKingdom, user-engine, tenant-engine, +flex-auth and affected extension/platform owners. Review the blueprint and +inventory every HTTP route, alias, MCP tool, embedded router and active platform +service/management surface. Record audience, action/resource, actor/target +tenant, enforcement point and test owner for each. Include Railiance Kubernetes, +GitOps/deployments, SSH, observability and platform identity/secret administration. +Confirm root's explicit cross-tenant administrative coverage and existing +approval obligations. Set the versioned security-profile and migration contract. + +Done when no published route/tool or active platform surface lacks a row and +owner, contract reviewers' decisions are recorded, and M1 success/deny cases +are executable specifications. Unknown/disputed rows remain visible blockers. + +## T02 — Bind platform-root identity, login, tenant and revocation + +```task +id: HUB-WP-0012-T02 +status: todo +priority: high +state_hub_task_id: "9a955fbf-f289-51b7-9682-bbe471694595" +``` + +Depends on T01. Owners: NetKingdom/KeyCape, user-engine and tenant-engine; +hub-core owns consumption. Resolve the existing root account to `(iss, sub)` +without recording credentials. Establish its explicit platform entitlement, +map existing platform-operator vocabulary, register Hub clients/audiences and +exact redirects, and implement PKCE sessions and API token validation. No +username comparison or first-login promotion. Require the existing AAL2 floor +and accepted enrollment/recovery; do not assume proposed IAM v0.4 step-up works. +Fix measurable session/token/assurance lifetimes and revocation bounds; include +live authoritative tenant/account checks for privileged actions. + +Done when attended root login succeeds privately, an ordinary account and a +forged same-name account fail, MFA/recovery/logout/key rotation work, and +suspension/grant withdrawal deny within the agreed bound. Record immutable +identity references and sanitized receipts only. Reuse NK-WP-0042 if additional +step-up implementation is actually required. + +## T03 — Deliver root policy and authenticated decision evaluation + +```task +id: HUB-WP-0012-T03 +status: todo +priority: high +state_hub_task_id: "feea8f20-aad4-583b-958a-a8efeb9c133c" +``` + +Depends on T01; live acceptance also needs T02. flex-auth owns the protected +system, complete action/resource grant and service deployment; platform owners +own credential/signing-key delivery. Hub Core owns enforcement integration. +Authenticate the calling workload separately from the end user, validate fact +provenance, signed decision origin, request binding and obligations. Root gets +all registered platform actions; non-root humans deny; callers get explicit +workload grants only. Fail closed on unsigned/untrusted, stale, mismatched, +unavailable or obligation-incomplete decisions. Prove audit durability and key +rotation. No token/PDP credential reuse from another protected system. + +Done when a private pinned deployment passes positive root decisions and the +tampered-signature, wrong actor/action/resource/tenant, expired decision, +untrusted caller and policy-outage matrix. Finished signing source work is not +substituted for evidence of production custody and delivery. + +## T04 — Enforce the boundary across Hub Core and its clients + +```task +id: HUB-WP-0012-T04 +status: todo +priority: high +state_hub_task_id: "15bc3cae-4575-56c9-afd2-e1e348109ca9" +``` + +Depends on T02/T03. Add the reusable verified actor/tenant context and local +enforcement seam to all native ports, projections, compatibility routes/aliases, +catalogs/docs, browser, MCP and embedded router paths. Minimal liveness and +login mechanics are the only public exceptions. Bind messaging/event producer +identity to the caller; prevent direct-Service bypass. Remove shared root +credentials from normal clients and confine unavoidable migration keys to +named private lanes. Add readiness checks for configured identity/policy +dependencies. Root can administer every Hub Core function; an ordinary logged-in +user cannot. Include revocation, concurrency, cache and audit-failure tests. + +Done when the route/tool inventory is covered by automated allow/deny tests, +private full-root browser/API/MCP journeys pass, and legacy callers have tested +bounded migration/rollback paths without a public bypass. + +## T05 — Admit extensions and State Hub migration callers + +```task +id: HUB-WP-0012-T05 +status: todo +priority: high +state_hub_task_id: "6d29854e-e894-5340-9e13-8866e80246f4" +``` + +Depends on T04. Publish the versioned extension security profile and harness. +Use ops-hub as first extension, then all inventoried exposed extensions; +activity-core, Repo Manager and inbox readers receive separate workload +identities. Each extension enforces audience/action/tenant and authenticates +delegation; no forwarding root tokens across audiences. Preserve domain/Fabric +authority and explicit unsupported/deferred surfaces. + +Done when root succeeds and anonymous/non-root/wrong-tenant/wrong-audience +callers fail across extension boundaries; calls and audit retain actor plus +workload identities. HUB-WP-0011-T02 consumes this contract, while its T01/T03 +retain freshness and reader cutover. STATE-WP-0079 keeps each slice's writer, +parity, retention and zero-traffic gates. This task does not claim retirement. + +## T06 — Prove full platform-root coverage, including Railiance (M1) + +```task +id: HUB-WP-0012-T06 +status: todo +priority: high +state_hub_task_id: "97b0b242-e9a7-53cd-941f-a1822fcf93a5" +``` + +Depends on T04/T05 and the external owners for each T01 row. Integrate the same +root identity/entitlement with all inventoried platform management surfaces. +Use native owner paths for SSH certificates, Kubernetes/RBAC, GitOps, +credentials and approvals; Hub Core is not an unrestricted execution proxy. +Keep caller and human attribution distinct and preserve existing confirmation +and approval obligations. Test allowed administration with reversible or +isolated operations and independently verify denied non-root attempts. + +M1 is accepted only when every coverage row has an attended/live receipt, +including full Hub Core access and Railiance administration, revocation and +audit. A navigation link or Hub Core token alone is not evidence of access to +another service. Any missing backend integration keeps M1 open. + +## T07 — Package and gate public exposure + +```task +id: HUB-WP-0012-T07 +status: todo +priority: high +state_hub_task_id: "0c15cb82-7c59-5a44-8bf0-857ea4438642" +``` + +Depends on M1. Owner: rapp-core-hub through existing RAPPCOREHUB-WP-0002-T05, +with NetKingdom/platform/reef owners. Pin the verified image, credential +references, policy boundary and explicit release exposure setting. Run local, +server-dry-run, private root/deny, TLS and consumer gates. Resolve the existing +publisher failures in RAPPCOREHUB-WP-0003 separately where required by smoke. +Obtain the concrete public-enable approval only after evidence is reviewable. +Routine upgrades preserve approved exposure; fresh installs stay private. +Rollback retracts public access before any pre-enforcement image is restored. + +Done when the approved public surface passes root access, non-root/anonymous +denial, no bypass, trusted TLS, revocation and rollback checks. Never enable +Ingress just to repair the old public stabilization check ahead of this gate. + +## T08 — Refine roles, tenant isolation and delegation (Phase 2) + +```task +id: HUB-WP-0012-T08 +status: todo +priority: medium +state_hub_task_id: "59a0672c-560e-5b43-9d83-9f90d498698f" +``` + +Deferred until M1; not an M1 dependency. Hub Core with NetKingdom, User/Tenant +Engine, policy and extension owners define tenant admins, ordinary users, +recipient rules, delegated agents and per-action/extension permissions. Migrate +legacy data with explicit tenant provenance; test query/export/cache/event and +MCP isolation before admitting any non-root tenant users. Root's platform grant +remains explicit and auditable. Do not create a second workplan merely to defer +this task; this plan stays open after M1 until Phase 2 is completed or explicitly +re-scoped with a durable owner. + +## Acceptance checkpoints + +- [x] Architecture/source/runtime review captured; new implementation owner is hub-core +- [ ] T01 contract review and complete platform surface inventory accepted +- [ ] M1: T02–T06 full platform-root access and denial/revocation evidence accepted +- [ ] T07: authenticated public exposure separately approved and verified +- [ ] Phase 2: T08 delegated and tenant-scoped access accepted + +Planning completion is not implementation completion. No authenticated root +session or entitlement was tested in the 2026-09-28 review.