Feature Status
Current support boundaries for identities, authentication methods, recovery, and OAuth.
Status describes shipped contracts, not production readiness or a compatibility promise.
Core
| Capability | Status | Included boundary |
|---|---|---|
| Assurance v2 | Implemented | Versioned evidence, local AAL, canonical AMR, and method/factor freshness. UV-passkeys and TOTP can establish local aal2; built-ins never claim aal3 |
| Identity-first accounts | Implemented | Stable User subjects with multiple separate Identity login records |
| Identity namespaces | Implemented | Global email; global or tenant-scoped username and registered custom kinds |
| Password authentication | Implemented | Sign-up and sign-in with an explicit identity; username-only accounts need no email |
| Custom primary methods | Implemented | Schema-backed application evidence can reuse AuthFlow, built-in MFA, sessions, cookies, and typed client extensions; the verifier remains application-owned |
| Email flows | Implemented | Identity verification plus global-email OTP, magic link, and password reset |
| Atomic registration | Implemented | Maintained stores create user, identity, and password credential in one transaction; custom stores must match this boundary |
| Recovery requirement policy | Implemented | Optional by default; applications can require enrollment and receive a limited session with a typed recovery requirement |
| OAuth identity bridge | Partial | Provider-account-first resolution, optional trusted provider email, collision detection, and atomic account creation. Maintained link-confirmation HTTP/client support and atomic link commit are missing |
Local assurance tiers do not automatically claim NIST SP 800-63 conformance. Recovery establishes constrained remediation, not a normal high-assurance session.
OAuth collisions return an explicit-link decision but do not have a maintained browser confirmation flow. The low-level OAuthLinkConfirmation primitive is server-only, app-owned, and non-atomic. A future maintained design requires an authenticated session-bound, provider-verified pending link plus atomic OAuthLinkCommit.
Opt-in modules
| Capability | Included | Application-owned or deferred |
|---|---|---|
| Identity management | Availability, list, add, replace, revoke, and primary-login operations through IdentityManagement, HTTP group, and client | Mutation authorization and step-up policy |
| Durable authorization | Subject-first permissions/roles, trusted CurrentPrincipal, scoped grants, CAS definitions, mandatory authorization for permission-definition HTTP, audit projections, and tested SQLite/D1/PostgreSQL stores | Credential mapping, ABAC, ReBAC, tenant mapping, role/grant/mapping administration HTTP, and broader IAM governance |
| Delegated access | Runtime-neutral Invitation and AccessGrant primitives, tested SQLite/D1/PostgreSQL stores, extension migrations, and recipes | HTTP/client presets and route authorization |
| CLI device login | RFC 8628 Effect-first services, durable SQLite/D1/PostgreSQL authorization state, poll/prepare/atomic consume-plus-token commit, separate start/approval operations, standard privacy-safe HTTP throttling, explicit token-grant registry, opaque Bearer credentials, verifier, Effect-native start/poll client, and retention | Approval UI/login continuation, explicit approval policy, permission mapping, additional custom-route CSRF/rate-limit/cache policy, OS keychain integration, and revocation cascades |
| TOTP | Ciphertext-only managed factors with required TotpSecretCipher, AES-256-GCM keyring, lazy old-key CAS rotation, HTTP operations, MFA, and step-up | Key custody, plaintext-row migration or re-enrollment, settings UX, and deployment policy |
| Login MFA | Flow-bound options plus atomic TOTP and recovery-code HTTP/client completion | Passkey login MFA until a feature-specific atomic commit port exists; policy and UX remain application-owned |
| Maintained storage | Complete SQLite/PostgreSQL/D1 migration catalogs plus focused direct Drizzle implementations for all 42 ports tracked in the project plan, including OAuth, audit logs, domain verification, security timelines, permissions, invitations, and access grants | Runtime composition, migration execution, database operations, and application-owned stores outside the maintained catalog |
See Permissions and Roles for the durable authorization model and its application-owned boundaries.
Deferred
| Capability | Boundary |
|---|---|
| Phone identity | No first-party phone/SMS module; a custom identity kind does not add E.164 normalization, verification, delivery, or recovery semantics |
Alpha migration breaks
Identity-first APIs do not support legacy email columns or compatibility payloads. Assurance v2 has no backfill path for earlier alpha session and TOTP rows; reset alpha development databases before applying the current baseline.
TOTP plaintext migration
The strict managed TOTP cipher has no plaintext fallback. Before strict cutover, temporarily deploy totpSecretCipherAes256GcmKeyringLegacyPlaintextMigrationLayer to lazily rewrite canonical Base32 rows as v1, or require affected users to re-enroll; remove the migration layer after verifying no legacy rows remain.
Identity invariants
Mutations use expectedUpdatedAt compare-and-set guards. Users cannot revoke their last login-eligible identity. Added emails start unverified; usernames and custom identities are locally verified. Revoked or replaced usernames become immediately reusable, and atomic uniqueness remains authoritative over advisory availability checks.