generated from coulomb/repo-seed
129 lines
4.2 KiB
Markdown
129 lines
4.2 KiB
Markdown
# Registration And Access Management UI
|
|
|
|
Status: implemented headless UI contract slice
|
|
Date: 2026-06-15
|
|
Related workplan: USER-WP-0014
|
|
|
|
## Purpose
|
|
|
|
This slice adds an optional NetKingdom registration and access-management UI
|
|
contract over the headless `UserEngineService`. It is not a credential UI and
|
|
does not own browser state. It provides transport-neutral screen models,
|
|
route contracts, and an accessible HTML renderer that web, desktop, or CLI
|
|
adapters can serve.
|
|
|
|
## Information Architecture
|
|
|
|
The implemented UI facade exposes these primary areas:
|
|
|
|
- registration
|
|
- prepared rights
|
|
- active hat
|
|
- profile
|
|
- onboarding
|
|
- admin
|
|
|
|
The supported views cover registration start/resume, factor status,
|
|
registration completion, prepared-account review and claim, active hat
|
|
selection, onboarding status, admin prepared accounts, admin access profiles,
|
|
and admin onboarding diagnostics.
|
|
|
|
## Public Facade
|
|
|
|
`RegistrationAccessManagementUi` lives in `user_engine.ui` and is exported from
|
|
`user_engine`.
|
|
|
|
It exposes:
|
|
|
|
- `information_architecture()`
|
|
- `api_contract()`
|
|
- `start_registration(...)`
|
|
- `attach_factor(...)`
|
|
- `complete_registration(...)`
|
|
- `registration_screen(...)`
|
|
- `prepared_rights_review(...)`
|
|
- `accept_prepared_claim(...)`
|
|
- `deny_prepared_claim(...)`
|
|
- `hat_selection_view(...)`
|
|
- `select_hat(...)`
|
|
- `admin_dashboard(...)`
|
|
- `render_html(...)`
|
|
|
|
## Route Contract
|
|
|
|
The UI route contract maps thin transport routes to existing headless service
|
|
facades:
|
|
|
|
- `registration.start` -> `start_registration`
|
|
- `registration.factor` -> `attach_registration_factor`
|
|
- `registration.complete` -> `complete_registration`
|
|
- `prepared_account.review` -> `list_prepared_accounts`
|
|
- `prepared_account.accept` -> `claim_prepared_account`
|
|
- `prepared_account.deny` -> UI dismiss decision
|
|
- `access_profile.select_hat` -> `select_active_hat`
|
|
- `admin.dashboard` -> diagnostics/list views
|
|
|
|
Proofing, IAM, authorization, notification, and protected service consoles
|
|
remain adapter boundaries.
|
|
|
|
## Registration Flow
|
|
|
|
The self-service UI facade can start registration, attach adapter-supplied
|
|
factor evidence, show safe factor status by type, enforce UI terms/consent
|
|
before completion, and show the resulting NetKingdom ID.
|
|
|
|
Factor values are never rendered. The flow displays factor types and status,
|
|
not email addresses, phone numbers, postal addresses, eID payloads, provider
|
|
tokens, or challenge material.
|
|
|
|
## Prepared Rights
|
|
|
|
Prepared-account review displays pending packages by id, display name,
|
|
required factor types, entitlement kinds, and status. Required factor values
|
|
are redacted. Accepting a package calls `claim_prepared_account`. Denying a
|
|
package is an explicit UI dismiss state and does not mutate prepared-account
|
|
domain state.
|
|
|
|
## Hats And Active Context
|
|
|
|
The active-hat view lists access profiles and the current active context.
|
|
Selecting a hat calls `select_active_hat`; the domain service still enforces
|
|
tenant, membership, factor, approval, and authorization rules. The UI does not
|
|
display hidden policy logic or final authorization decisions.
|
|
|
|
## Admin Surface
|
|
|
|
The admin dashboard composes existing diagnostics and list operations:
|
|
|
|
- registration diagnostics
|
|
- tenant diagnostics
|
|
- prepared-account counts
|
|
- access-profile counts
|
|
- onboarding diagnostics
|
|
|
|
The dashboard intentionally reports counts and lifecycle gaps without exposing
|
|
factor values, prepared-account factor matches, profile default values, claim
|
|
values, or raw proofing payloads.
|
|
|
|
## Accessibility And Layout
|
|
|
|
The renderer emits semantic landmarks:
|
|
|
|
- `banner`
|
|
- `navigation`
|
|
- `main`
|
|
|
|
Sections are linked from navigation, action controls expose `aria-label`, and
|
|
mobile/desktop layout metadata is available through the screen model. Mobile
|
|
screens use one column with a 44px minimum touch target; desktop screens use a
|
|
two-column workbench layout.
|
|
|
|
## Current Limits
|
|
|
|
- This slice does not ship a web server, JavaScript client, or CSS bundle.
|
|
- Browser persistence is not authoritative over domain state.
|
|
- The HTML renderer is a verification artifact and adapter starting point, not
|
|
a final branded application.
|
|
- Credential entry, password reset, passkeys, MFA challenges, token issuance,
|
|
notifications, and service-specific consoles remain outside user-engine.
|