Files
user-engine/docs/registration-scenario-and-security-conformance.md

3.1 KiB

Registration Scenario And Security Conformance

Status: implemented conformance slice Date: 2026-06-15 Related workplan: USER-WP-0015

Purpose

This slice turns the NetKingdom registration and onboarding roadmap into an executable local conformance contract. It proves that the headless APIs and the optional UI contract can complete the main registration journey, fail closed on security negative paths, redact sensitive values, and exercise adapter seams without production infrastructure.

Scenario Matrix

The registration matrix is defined in user_engine.testing.scenarios as REGISTRATION_SCENARIO_MATRIX.

It covers:

  • self-registration;
  • prepared account claim;
  • privileged role requiring approval;
  • eID-backed assurance;
  • family invite;
  • tenant admin invite;
  • group access;
  • denied cross-tenant claim.

The broader SCENARIO_MATRIX now also names registration/onboarding, prepared-claim, group-access hat, denied cross-tenant claim, and UI workflow coverage.

End-To-End Conformance

tests/test_registration_security_conformance.py includes a full local flow:

register application/catalog
prepare account with onboarding hint
complete email-backed registration
claim prepared account
select active hat
read claims projection and identity context
export access-control facts
render admin UI
assert onboarding event emission and redaction

This proves the path from registration through identity context, claims enrichment, active access context, access fact export, onboarding, and UI diagnostics.

Security Negative Paths

The conformance suite exercises fail-closed behavior for:

  • weak factor requirements;
  • duplicate identity links;
  • prepared-account hijack attempts;
  • expired prepared claims;
  • missing or cross-tenant context;
  • privileged prepared roles requiring approval;
  • stale approval through approval-required access profiles.

Denied prepared-account claim decisions leave audit evidence without creating memberships for the attacker or emitting successful activation events.

Redaction And Diagnostics

Conformance checks assert that these values do not leak through diagnostics, events, or UI output:

  • normalized factor values;
  • email addresses used for prepared account matching;
  • sensitive profile values;
  • access profile claim/default values;
  • proofing adapter secret input.

Sensitive profile values are redacted in runtime projections as <redacted>.

Adapter Conformance

The local adapter conformance path covers:

  • factor verification adapter normalization;
  • authorization harness request capture and obligations;
  • access-control fact export;
  • onboarding handoff lifecycle gaps and resume;
  • audit record availability;
  • outbox replay through pending events;
  • in-memory durable-store rollback behavior in existing port tests.

No provider-specific IAM, eID, SMS, email, authorization-engine, notification, or workflow infrastructure is required.

Commands

make test
make test-conformance

The Makefile targets currently run the same standard-library test suite. They remain separate entry points so CI can split unit, integration, scenario, and conformance execution later.