chore(consistency): sync task status from DB [auto]

Updated by fix-consistency on 2026-08-09:
  - USER-WP-0022-T01: progress → wait
This commit is contained in:
custodian-sync 2026-08-09 22:27:34 +02:00
parent 1f25052d02
commit b7378b7623

View file

@ -0,0 +1,133 @@
---
id: USER-WP-0022
type: workplan
title: "Public registration and JIT application profiles"
domain: communication
repo: user-engine
status: active
owner: codex
topic_slug: netkingdom
created: "2026-08-09"
updated: "2026-08-09"
depends_on:
- USER-WP-0021
- NK-WP-0025
state_hub_workstream_id: "97145e5b-5f8f-4cb1-9135-2593f5baac8f"
---
# USER-WP-0022 - public registration and application JIT
Turn the existing provider-neutral registration domain into a safe public
product flow and provide idempotent first-login application-profile creation.
user-engine remains the user/profile source of truth but delegates login
identity creation to NetKingdom.
## T01 - Publish the public registration journey
```task
id: USER-WP-0022-T01
status: wait
priority: high
state_hub_task_id: "43dd49b7-6dbc-4117-a401-6d9f6e59aa26"
```
Add accessible browser/API entry points for start, email verification,
provider password-setup handoff, resume, expiry, cancel, and completion.
Enable public registration only through explicit runtime configuration and
signed allow-listed return context. Apply rate limits, anti-enumeration
responses, CSRF, idempotency, and safe diagnostics.
Done when the flow can be enabled per deployment without exposing whether an
email or username already exists.
Implementation contract established in NetKingdom at
`docs/public-registration-orchestration-contract.md`. The current
authenticated registration API will not be moved ahead of authentication;
the public adapter will use opaque intent handles and construct a narrowly
scoped applicant actor only from consumed verification evidence. First code
slice added `RegistrationVerificationPort`, bound request/receipt/evidence
types, and a fail-closed HTTP adapter with purpose checking and normalized
mailbox evidence. Adapter tests and the full 123-test suite pass.
## T02 - Orchestrate provider identity creation
```task
id: USER-WP-0022-T02
status: progress
priority: high
state_hub_task_id: "74239ce4-5c1e-46cf-8abf-3cbec3f3f989"
```
Use the existing provisioning port to create or resume an ordinary NetKingdom
identity only after required verification. Persist lifecycle intent and outbox
state atomically; compensate or surface recoverable partial state on provider
failure. Never accept or retain an LLDAP password, admin credential, MFA seed,
or verification secret in the user-engine domain.
Done when a registration can resume safely across timeout/retry and produces
one external identity link.
The existing provisioning port remains the privileged boundary. Public
registration adds canonical username and uses the registration ID as its
stable idempotency key; it accepts only the baseline ordinary-user group and
the provider-owned password-setup handoff. `ProvisioningRequest` now carries
an optional canonical `preferred_username` through the HTTP adapter without
changing existing callers.
## T03 - Create application profiles on first login
```task
id: USER-WP-0022-T03
status: cancel
priority: high
state_hub_task_id: "01fa1a22-0f4a-4a36-a9b3-0f94d3c70be1"
```
Implement an idempotent ensure-application-profile operation keyed by
application plus verified issuer and subject. Seed only approved profile
defaults and preserve application ownership of application-specific data.
Verified email may suggest an explicit link to an existing local profile but
must never authorize an automatic takeover.
Done when repeated OIDC callbacks return the same profile and collisions
require explicit authenticated resolution.
Cancelled here because application profiles are application-owned. The
coulomb-social consumer implements this under CSOC-WP-0003 using its unique
`(issuer, subject)` Member binding; user-engine continues to supply `/me`.
## T04 - Carry assurance and step-up requirements
```task
id: USER-WP-0022-T04
status: cancel
priority: high
state_hub_task_id: "d3bec8c6-e8d8-46d5-8fa2-b4675ff1ade8"
```
Model the application's minimum assurance and per-user/profile step-up policy
as data consumed by KeyCape/application authorization. Do not let profile data
issue tokens or weaken client minimums. Add a reauthentication/step-up handoff
that returns to the intended action after fresh OIDC authentication.
Done when a regular profile can be password-only while a profile or protected
action can require MFA without changing global identity facts.
Cancelled here in favor of KEY-WP-0008 client policy and CSOC-WP-0003 action
step-up. user-engine must not become the token assurance authority.
## T05 - Registration and JIT security matrix
```task
id: USER-WP-0022-T05
status: todo
priority: high
state_hub_task_id: "0a5a5f3a-0d47-4d5d-bda5-e2c7c737fee6"
```
Cover enumeration resistance, duplicate username/email, verification
replay/expiry, provider outage and compensation, return-state tampering, JIT
replay, account-link collision, cross-tenant profile access, step-up downgrade,
unlink, and deletion. Verify audit/outbox redaction and correlation.
Done when the full suite and deployed consumer conformance both pass.