Skip to content

ADR 0011: Desktop Identity Model

Decision

BooksPlus desktop installations should use the operating system account as the first trust boundary.

For the desktop MVP, BooksPlus should not begin by creating a separate web-style username and password system. Instead, BooksPlus should assume that the person operating the application is the person currently signed in to the desktop operating system.

BooksPlus should maintain its own internal actor/user records, but those records should be mapped to local operating system identities, service identities, or explicitly authorized support identities.

Rationale

BooksPlus is planned as a desktop-licensed application. The desktop operating system already provides a user account boundary, credential storage, device access controls, and optional biometric or PIN-based unlock mechanisms.

Creating a separate password system too early would add complexity without solving the main accounting-security problem. The primary security question for BooksPlus is not merely "who logged in?" but:

Which actor is allowed to perform which accounting verb, on which object, in which period, with what audit evidence?

Implications

BooksPlus should distinguish between:

  • device trust;
  • operating system identity;
  • BooksPlus actor identity;
  • application permissions;
  • audit evidence.

The application should be designed so that higher-assurance confirmation can be added later for sensitive actions, such as Windows Hello, macOS biometric confirmation, passkeys, or another platform-specific step-up mechanism.

Guidance

For MVP:

  • map BooksPlus actors to local OS users where practical;
  • do not store ordinary user passwords unless a later multi-user deployment model requires it;
  • support disabled and retired user states;
  • never delete users who have historical activity;
  • preserve historical actor identity in audit trails and accounting records.