Close recovery acceptance and reconcile blocked workplans
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0e38e-e5bb-7b50-968d-a738a0294997
This commit is contained in:
parent
b73f553c18
commit
eca7c54748
9 changed files with 162 additions and 46 deletions
|
|
@ -2,9 +2,9 @@
|
|||
|
||||
Owner: user-engine, with KeyCape/NetKingdom for sign-in and factors,
|
||||
tenant-engine for tenant lifecycle, and applications for workload admission.
|
||||
Acceptance work: USER-WP-0027; OTP dependency: KEY-WP-0035 and NK-WP-0033.
|
||||
Acceptance work: USER-WP-0027/0028; provider implementation: KEY-WP-0035 (finished).
|
||||
Reviewed against the portal on 2026-09-13. U01, U09 and U10 were revised on
|
||||
2026-09-26. This is the browser acceptance contract;
|
||||
2026-09-26; acceptance dependencies were reconciled on 2026-09-27. This is the browser acceptance contract;
|
||||
headless capability alone does not mean a journey is usable or verified live.
|
||||
|
||||
## Common interaction rules
|
||||
|
|
@ -43,16 +43,16 @@ headless capability alone does not mean a journey is usable or verified live.
|
|||
| ID / intent | Success | Failure and recovery | Current support / acceptance |
|
||||
|---|---|---|---|
|
||||
| U01 — Know whether I am signed in | Header and the home page say “Signed in as” the verified identity when an account-site session exists. With no account-site session they say “Not signed in,” unless the sign-in service confirms an existing NetKingdom identity, which is then named before the account site continues. An application may keep its own session. A one-time code is a higher security level, not another sign-in | Expired/unknown cookie shows signed-out state; a query does not invent a session; a failed identity lookup stays signed out; sign in again, or use a different identity | Implemented; automated anonymous/expired/member/operator tests, including the home identity section and a confirmed NetKingdom sign-in with no account-site session |
|
||||
| U02 — Sign in to my company application | Personal login lands in the intended tenant and application | Wrong credentials stay on provider; denied membership leads to account help with identity switching | Recovery deployed previously; actual fresh-user acceptance waiting on OTP |
|
||||
| U02 — Sign in to my company application | Personal login lands in the intended tenant and application | Wrong credentials stay on provider; denied membership leads to account help with identity switching | Fresh application login confirmed on September 24; second-user, setup-to-welcome and company-workflow acceptance remain VERGABE-WP-0019-T06 |
|
||||
| U03 — Accept an invitation | Confirm intended tenant/role, accept once, then see next setup step | Expired/used/wrong-person invitation explains next step; admin reissues without duplicates | Service/browser routes exist; live delivery and full browser acceptance pending |
|
||||
| U04 — Set or recover my password | Use actual login name, complete single-use setup, return to sign-in | Missing mail or expired link offers admin-assisted new setup link | Password setup reported successful; login name and sign-in address now named at handoff and in the user entry (2026-09-23 run, USER-WP-0035-T01); email delivery unresolved (USER-WP-0035-T02) |
|
||||
| U05 — Use password-only access before optional OTP enrollment | Ordinary application permits login when provider confirms no activated factor | Provider unavailable gives recovery, never silently bypasses enrolled OTP | KEY-WP-0035 source tested; live credential/policy gate unresolved |
|
||||
| U06 — Turn on authenticator codes voluntarily | My account → Sign-in security → provider; confirm identity, scan QR, verify current code, see activation confirmed, test fresh login | Bad code retries; cancellation does not report enabled; interruption can resume safely; support reachable without portal login | Help and configurable provider handoff implemented; provider activation/cancel semantics and live enrollment unverified |
|
||||
| U05 — Use password-only access before optional OTP enrollment | Ordinary application permits login when provider confirms no activated factor | Provider unavailable gives recovery, never silently bypasses enrolled OTP | Renewable factor-reader and optional policy deployed (KEY-WP-0035/RPF-WP-0040); installed-provider checks pass; attended full U05–U08 acceptance remains USER-WP-0028-T03 |
|
||||
| U06 — Turn on authenticator codes voluntarily | My account → Sign-in security → provider; confirm identity, scan QR, verify current code, see activation confirmed, test fresh login | Bad code retries; cancellation does not report enabled; interruption can resume safely; support reachable without portal login | Installed-provider activation/cancellation checks pass (P06); real-user enrollment and verified portal handoff remain USER-WP-0028-T03 |
|
||||
| U07 — Sign in with an enrolled authenticator | Current code completes login; existing AAL1 session cannot skip OTP | Invalid code explains retry; lost device has a recovery route | Issuer policy tested; real-user enrolled/recovery acceptance pending |
|
||||
| U08 — Replace or remove my authenticator | Provider reauthenticates; replacement verified before old factor removed; status and recovery instructions clear | Lost old factor triggers verified recovery, not a bypass link; policy-required MFA cannot be disabled | Required provider journey; not verified/available from portal yet |
|
||||
| U08 — Replace or remove my authenticator | Provider reauthenticates; replacement verified before old factor removed; status and recovery instructions clear | Lost old factor triggers verified recovery, not a bypass link; policy-required MFA cannot be disabled | P04 recovery and P06 replacement guards deployed and verified with disposable provider fixtures; real-person recovery/replacement acceptance remains USER-WP-0028-T03 |
|
||||
| U09 — See my tenants and usable applications | Account page and home show login state, the tenants and privileges active on this sign-in, and allowed memberships separately. An ordinary sign-in has one active tenant. An administrator, vendor, or multi-hire sign-in may show more than one active tenant when the verified token lists them. A recorded workload membership is an allowed record | An empty allowed list says nothing is recorded. A tenant account or the token tenant is not shown as a membership. A missing catalogue decision is not checked, which is neither access nor a denial | Login state, active sign-in, and allowed memberships are shown (USER-WP-0036). Allow, deny, and unavailable workload decisions remain USER-WP-0026-T03 and USER-WP-0028-T02 |
|
||||
| U10 — Change tenant or account | Explicit reauthentication confirms the new tenant. Other allowed tenants stay inactive until that sign-in. Switching does not claim to end sessions an application already has | Denied tenant leaves a clear recovery route; stale shared identity can be cleared. A portal control does not mark a second tenant active by itself | Reauthentication handoff is the only tenant switch; real multi-identity acceptance pending |
|
||||
| U11 — Sign out | Confirmation states scope; portal session ends; correct signed-out controls appear | CSRF rejection retains session; shared-provider failure explains remaining scope and retry | Portal automated tests; prior shared logout browser checks; current real-user acceptance pending |
|
||||
| U10 — Change tenant or account | Explicit reauthentication confirms the new tenant. Other allowed tenants stay inactive until that sign-in. Switching does not claim to end sessions an application already has | Denied tenant leaves a clear recovery route; stale shared identity can be cleared. A portal control does not mark a second tenant active by itself | Account switching confirmed by the founder on September 24 with fresh issuer sequences (USER-WP-0026-T02); multi-user workload acceptance remains VERGABE-WP-0019-T06 |
|
||||
| U11 — Sign out | Confirmation states scope; portal session ends; correct signed-out controls appear | CSRF rejection retains session; shared-provider failure explains remaining scope and retry | Automated scope/CSRF tests, live shared-logout checks and September 24 attended account-switch receipt complete USER-WP-0026-T02; existing application JWTs are not revoked |
|
||||
| U12 — Recover from denied access or service outage | Plain explanation, reference for support, and account/help navigation | No automatic login loop; no private claims/codes echoed; safe retry only | HTML browser denial/recovery implemented; JSON API semantics retained |
|
||||
| U13 — Update my profile and finish onboarding | Saved values and required steps are confirmed; external steps reflect provider evidence | Validation keeps safe input; provider-owned steps cannot be manually faked complete | Existing routes; form-preservation and external completion UX acceptance pending |
|
||||
|
||||
|
|
@ -63,7 +63,7 @@ headless capability alone does not mean a journey is usable or verified live.
|
|||
| T01 — Enter the right tenant administration | Header shows identity; managed tenant is explicit; only permitted admin navigation | Non-admin/cross-tenant request denied with account recovery | Existing authorization/navigation tests; broader browser matrix pending |
|
||||
| T02 — Invite someone with the right role | Review name, email, tenant and role; show invitation state and next action | Duplicate, wrong address, expired invite: inspect, correct/reissue or expire without making a second account | Invitation routes and checks exist; delivery/preview usability pending |
|
||||
| T03 — Prepare an account that can actually log in | Distinguish profile, directory login name, invitation, password setup, and tenant access; admin can give the correct login name | Partial provisioning shows what exists and retry reconciles it; never show display name as login implicitly | Create-login/setup-link routes exist; login name and sign-in address presented in the user entry (USER-WP-0035-T01); lifecycle state view pending |
|
||||
| T04 — Help someone who cannot sign in | Identify affected tenant/account; distinguish password, OTP, membership, and outage; give safe recovery step | No access to passwords, OTP seed or current codes; provider failure has support reference/escalation | Password setup and help page exist; verified lost-factor recovery/provider status pending |
|
||||
| T04 — Help someone who cannot sign in | Identify affected tenant/account; distinguish password, OTP, membership, and outage; give safe recovery step | No access to passwords, OTP seed or current codes; provider failure has support reference/escalation | P04 recovery and provider status implemented/deployed; tenant admins escalate to authorized platform recovery; real-person lost-factor acceptance remains USER-WP-0028-T03 |
|
||||
| T05 — Grant/change/revoke application access | Review exact tenant/application/role; apply authorized change; confirm effective result | Policy denial or stale version explains reason and refresh; no silent broad grant | Service capabilities vary; consolidated browser application-access management pending |
|
||||
| T06 — Suspend/reactivate/remove a tenant account | Confirm target and scope; show resulting state and whether access propagation is pending | Stale or failed operation leaves truthful state; retry after readback; shared identity in other tenants preserved | Existing lifecycle routes; confirmation/propagation UX and cross-tenant browser drills pending |
|
||||
| T07 — Track incomplete onboarding | See invited, identity missing, password pending, OTP problem, and access denied as distinct actionable states | Stale/unknown provider state is labelled; administrator gets the correct owner/action | Headless diagnostics exist; consolidated browser status and retry workflow pending |
|
||||
|
|
@ -119,8 +119,9 @@ delivery readout, onboarding follow-up, tenant audit, and platform delivery retr
|
|||
|
||||
## Acceptance and remaining work
|
||||
|
||||
USER-WP-0027 tracks the matrix and role-based usability gaps. KEY-WP-0035 tracks
|
||||
OTP policy/provider rollout. USER-WP-0026 retains authoritative workload catalogue
|
||||
USER-WP-0027 tracks the matrix and role-based usability gaps. KEY-WP-0035
|
||||
completed OTP policy/provider rollout; USER-WP-0028-T03 retains attended OTP
|
||||
acceptance. Credential custody is no longer a blocker. USER-WP-0026 retains authoritative workload catalogue
|
||||
work. Do not close these based solely on this document or a unit-test pass.
|
||||
|
||||
Run every journey with an ordinary member, tenant admin, and platform operator as
|
||||
|
|
@ -133,3 +134,11 @@ Automated portal coverage: test_account_clarity.py, test_account_recovery.py,
|
|||
test_portal_navigation.py and existing test_web.py authorization/lifecycle tests.
|
||||
Automated issuer coverage: KEY-WP-0035 optional MFA tests. Actual provider OTP,
|
||||
notification delivery and multi-user workload acceptance remain separate evidence.
|
||||
|
||||
September 27 reconciliation: the credential/policy deployment gate above passed
|
||||
under RPF-WP-0040 and P06; it is still a prerequisite for any future handoff
|
||||
configuration. KEY-WP-0034 and the September 24 attended receipt close the prior
|
||||
account-switch wait. Mail infrastructure is available, but provider setup-link
|
||||
delivery and invited-person receipt remain USER-WP-0035-T02. See
|
||||
[evidence review](evidence/2026-09-27-loose-ends-review.md) for the exact evidence
|
||||
and remaining owner dependencies.
|
||||
|
|
|
|||
42
docs/evidence/2026-09-27-loose-ends-review.md
Normal file
42
docs/evidence/2026-09-27-loose-ends-review.md
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
# Loose-end review — 2026-09-27
|
||||
|
||||
Reviewed all 37 workplan files: 32 finished and five active. No ready,
|
||||
proposed, backlog or already-blocked workplans were present. The five open
|
||||
workplans are now blocked; no task or workplan was created.
|
||||
|
||||
## Completed existing task
|
||||
|
||||
USER-WP-0026-T02 is done. The immutable release and anonymous browser evidence
|
||||
in `railiance-apps/docs/evidence/2026-09-12-account-recovery-live.md` is now
|
||||
supplemented by `key-cape/docs/evidence/2026-09-24-fresh-login-and-account-switch.md`.
|
||||
The founder confirmed fresh login/account switching; issuer telemetry records
|
||||
three fresh portal authentication/token-issuance sequences following an MFA
|
||||
failure. KEY-WP-0034-T02 is also done. U10 now reflects this evidence.
|
||||
Application JWTs may outlive provider logout. The receipt does not complete the
|
||||
second-user/company-workflow pilot in VERGABE-WP-0019-T06.
|
||||
|
||||
## Remaining blockers
|
||||
|
||||
| Workplan / tasks | Current dependency and resumption condition |
|
||||
| --- | --- |
|
||||
| USER-WP-0026-T03, USER-WP-0028-T02 | Application/authorization owners must establish the supported workload catalogue, registered HTTPS entry points, identity/tenant/action mapping, authoritative decisions and scoped grant/revocation contract. Local application records, memberships and the PDP evaluator do not supply fleet admission. |
|
||||
| USER-WP-0027-T04, USER-WP-0028-T03 | Attended real-user OTP enrollment, cancellation, replacement/lost-factor recovery and fresh-login acceptance; verified portal setup handoff. KEY-WP-0035 and RPF-WP-0040 already delivered credential custody, renewal and optional policy. P04/P06 prove the implementation using disposable installed-provider fixtures. NK-WP-0033's separate incident also closed on September 23. |
|
||||
| USER-WP-0027-T06 | Full matrix depends on the preceding application/OTP work, setup-link delivery and VERGABE-WP-0019-T06 second-user/setup-to-workflow acceptance. |
|
||||
| USER-WP-0034-T02 | FLEX-WP-0020 section 8 still waits for the renamed canonical checkout. `/home/worsch/access-engine` is absent; `/home/worsch/flex-auth/docs/iam-profile-consumption.md` exists. Keep the current source link until registration. |
|
||||
| USER-WP-0035-T02 | The provider-owned password-setup link still needs a supported delivery handoff and intended-person receipt evidence. EMAIL-WP-0004 and P05 delivered the mail service; its invitation outbox adapter is not a setup-link delivery contract. |
|
||||
|
||||
The review corrects stale missing-credential and missing-mail-infrastructure
|
||||
claims rather than requesting replacement secrets or rebuilding working provider
|
||||
features. Existing tasks retain all remaining work. No production configuration
|
||||
or real account was changed, and no email was sent.
|
||||
|
||||
## Validation
|
||||
|
||||
- `make test`: 264 tests run, eight optional integration skips, no failures;
|
||||
layer conformance passed.
|
||||
- `make test-journeys`: 66 tests passed, no skips. The report remains incomplete
|
||||
for U02–U09, T02, T04 and T05; account switching U10 is no longer a blocker.
|
||||
- `git diff --check`: passed.
|
||||
|
||||
Local tests validate the implementation and journey mappings. They do not
|
||||
substitute for the external acceptance evidence listed above.
|
||||
Loading…
Add table
Add a link
Reference in a new issue