Taifa Identity. Docs
OpenAPI Developers

Manage access

Enrollment and recovery

Planned2 min read View .md

Enrollment and recovery

Strong sign-in and workforce admission are separate decisions. The Go issuer can verify password plus TOTP and optional passkeys for a synthetic local account. It cannot yet enroll a real person through the complete reviewed, holder-bound, Mail-delivered activation journey.

Sign in with current factors

The portal BFF starts an OIDC transaction and binds it to an HttpOnly challenge cookie, CSRF protection, and the private issuer challenge. Password plus TOTP produces acr=taifa-mfa. A registered passkey must prove user presence and verification and produces acr=taifa-phishing-resistant. A client may request stronger assurance; the verified result must actually meet it. Platform administration requires phishing-resistant assurance and an actual auth_time within five minutes.

When passkeys are configured, the issuer exposes private authentication begin and finish routes to the BFF. Registration needs a recent strong session and a discoverable, user-verifying credential. The registration ceremony is versioned, one-use, and expires after at most two minutes. The BFF completes registration before the issuer consumes the OIDC auth request. These private routes are not an application SDK or a public enrollment API.

Admit a real person

A live Institution sponsor proposes a new central Person for the approved Institution. A different authorized reviewer approves the exact identity and context. The management service has fresh standalone enrollment records and private admission grant, acknowledgement, and activation-proof routes. Activation is disabled by default. The issuer’s one-use grant acceptance, holder invitation, credential setup, quarantine release, and complete Mail bridge remain unwired. Do not mark a Person active on review alone or send a synthetic bootstrap credential to a real person.

A delivery email is a way to reach a holder, not proof that the holder owns an existing local account or has completed factors. Admission must bind a one-use invitation to a protected portal session, finish real factors, obtain a management activation proof and a fresh authority lease, then release that exact credential generation.

Recover access

A lost factor or inaccessible account needs a separately audited, scoped review with independent approval and fresh strong reviewer authentication. Email possession alone cannot authorize privileged recovery. The old credential and session state must be contained, and a recovered account must retain the same issuer and subject unless a separately reviewed replacement identity is required. The owned issuer’s complete recovery ceremony is a release gate. No self-service recovery URL is promised here.

Verify before launch

Test user-verifying passkeys on supported authenticators, password plus TOTP, lost-factor recovery, expired and repeated invitations, sponsor or reviewer revocation, cancellation during setup, Mail failure, and cross-service activation. See platform status for the release boundary.

Popular

Browse by section