Platform status
Use this page to choose a safe starting point. A source implementation or API contract is not a deployed production service.
| Capability | State | What you can do now |
|---|---|---|
| Go OIDC issuer with authorization code, PKCE S256, RS256 keys, password plus TOTP, optional passkeys, refresh rotation | Isolated development | Run isolated issuer tests and the HTTPS two-client synthetic browser acceptance. |
| Separate custom Svelte authentication UI and portal login transactions | Development | Exercise password/TOTP, resident virtual passkeys, silent two-client SSO and native forms with JavaScript disabled. |
| Python management API, governance, audited mutations, lifecycle feed and snapshots | Implemented contract | Inspect the generated schema and run service tests. Deployment and authority configuration still require review. |
| Signed workforce lease receiver | Isolated integration | Verify a reviewed subject mapping against the private publisher. Synthetic bootstrap accounts cannot receive workforce authority. |
| Reviewed enrollment, service identity and Mail delivery workflows | Management boundary | Review the API contract and scoped source tests; genuine holder and product acceptance remain separate. |
| Registry-backed confidential web clients | Isolated integration | Test two client policies, exact callbacks, audiences, revocation and refresh isolation. Reviewed provisioning remains a gate. |
Private holder setup API, custom /setup UI, server-owned password/TOTP enrollment, signed cancellation and durable activation retries | Development wiring | Test bound setup and isolated recovery. The invitation/Mail bridge is implemented. Real reviewed holder acceptance, effective product delivery and privileged passkey enrollment remain gates. |
| Central browser SSO | Mounted development acceptance | Two synthetic confidential clients redeem verified tokens with separate audiences/cookies and one central SID. Real project assignments and product rollout remain gated. |
| Independent catalog and owned-client policy review | Management boundary | Propose and review immutable client/catalog revisions. Client approval waits for a separately verified registration readback; it does not enable sign-in. |
| Owned-client credential delivery tool and private custody receiver | Qualified Linux handoff | Focused tests cover protected files, signed intent/receipt validation, verified TLS, PostgreSQL persistence and acknowledgement. Current-owner intent creation, connected Management delivery and reviewed registration installation remain gates. See credentials and rotation. |
| Independent exact Access-version and grant-Event review | Management boundary | An actual Sponsor and a different effective administrator record immutable decisions. Current grant facts and product Event acknowledgment are separate GET fields; signed issuer assignment remains a gate. |
| Full logout, production admission, recovery and signing-key rotation | Release gate | Complete real product, strong-authentication and operational acceptance before rollout. |
What this means for applications
The portal BFF remains explicitly configured as taifa-identity-portal; the issuer resolves client policy through its reviewed registry. Web and native examples in this repository show standards-based integration patterns and have injected tests, but they are not registered against the owned issuer. The mounted development runner separately registers two synthetic confidential clients and verifies the actual Go/UI/HTTPS flow. A product must wait for reviewed client provisioning, independently approved person assignments and a production issuer before enabling mandatory sign-in.
The management service still contains legacy provider delivery paths while the owned engine is being built. They are migration and rollback artifacts, not the target platform. Public examples here describe the owned-engine contract and clearly label what cannot yet be executed against it.
Release checks
Before a real deployment, validate reviewed provisioning and initial privileged admission, recovery, multi-client SSO, logout and back-channel revocation, key rotation, PostgreSQL 16, migrations and restore, ingress isolation, edge rate limits, real authenticators, product lifecycle catch-up, and an end-to-end Mail journey. Record measured acceptance in private release evidence. The deployment and migration guides describe the work an operator must complete.