Parked: could the identity and access code be a standalone Marten package

**Parked, not planned.** This records the reasoning while it is fresh, so it is not re-derived from scratch later or started on a whim.

## The idea

Extract the identity and access code into a package that any Marten application can use: users, password handling, lockout, MFA, refresh tokens with rotation, email verification, roles and groups.

## Why it is worth considering

There is no good Marten-native identity package. A team on Marten today either hand-rolls it, which is what this repository did, or runs ASP.NET Identity alongside it, which means two ORMs and often two databases in one application, because Identity assumes a relational store and an `IdentityDbContext`.

That gap is real and the audience is specific: .NET teams who chose Marten and then discovered identity was their problem.

The code is also more separable than most. `ISecretProtector`, `IOtpService`, `IDeviceGate` and `IEmailVerificationService` are already public interfaces. The documents are self-contained. Refresh rotation with reuse detection and TOTP replay protection via `MfaSecret.LastUsedTimeStep` are already implemented rather than aspirational.

## Three things that make it harder than it looks

**Tenancy becomes a configuration surface.** `User` is `.SingleTenanted()` on purpose, because identity is global while permissions resolve per tenant. A package cannot assume either shape, so tenancy has to be exposed as a choice, and conjoined tenancy is a Marten concept the consumer then has to understand to configure it correctly.

**The distinctive half is the coupled half.** What makes this model better than ASP.NET Identity is capabilities as an allowlist with tenant-aware resolution, and that lives in `PermissionResolver` and `SystemCapabilities`, which know about content types. A general package must not. So either it ships the ordinary part, users and passwords and MFA and tokens, and leaves behind the part worth having, or it drags CMS concepts into a package that should not have them.

**It becomes a public contract.** `Features/*` is `internal` today, which is exactly what allows an endpoint to change freely. Extracting promotes a surface and promises not to break it, the same problem `DECISIONS.md` D18 settles for the module contract and #635 raises for the console descriptor. Once somebody outside depends on it, the shape is fixed.

## The test to apply before starting

**Would barakoCMS consume the package, or keep its own copy?**

If it would consume it, the extraction is honest and the package is real. If barakoCMS would keep its own because the package had to be too general, then what exists is a fork that rots, which is the standard failure of every "extract the good bit" project.

That is the same test that settled the module UI descriptor: the first-party use is the acceptance criterion, not a nice-to-have.

## Timing

Not before 4.0. Probably not before the module ecosystem exists, because that is the thing that shows whether anybody wants pieces of barakoCMS separately at all. If nobody ships a module, nobody wants the identity package either.

## What to do in the meantime

Nothing specific to this, and nothing that forecloses it. #638, #639 and #640 are fixes worth making regardless, and each moves the code toward something extractable rather than away.

Avoid the opposite: do not add new coupling between the auth documents and CMS concepts without noticing. That is the cost that accrues quietly and is paid all at once.

## Closing this

Close it when either the answer is no, with the reason, or the module ecosystem exists and the question can be asked with evidence instead of a guess.

Start with the issue's references to Features/*, PermissionResolver, SystemCapabilities, DECISIONS.md D18, and issues #638, #639, and #640. This is parked design work rather than an implementation task; it is done when the module ecosystem provides evidence for or against extraction, with the answer documented and the issue closed.

Written by the indexing model from the issue text.