DATA-WSF-002 — Use immutable subject identity for roots and ACLs

Field	Value
Status	Open; source-verified
Severity	High
Components	sparqd/workspace-file-management-backend, identity/account services, sparqd/oqullus
Associated issues	Not opened

Concrete observed case

The deployed backend selects the first available identity from preferred_username, azp, client_id, and sub. It uses that string as the user root name, permission subject, creator, trash actor, and history actor. Oqullus grants access using the email returned by account members. A username or email change can therefore create a new root or disconnect existing ACLs from the same human account. Falling back to a client identity can also produce a different subject shape.

Backend main adds explicit owner_id, which removes inference from folder name, but the stored owner and ACL remain the mutable selected username string.

Expected condition

Ownership and ACLs use the realm-scoped immutable user sub. Email and username are mutable display attributes resolved from the account authority. Service principals have a distinct typed subject.

Why it matters

Profile renames, email changes, account recreation, or differing token claims can orphan a user's root, retain stale access, or make valid grants ineffective.

Existing controls and workarounds

Current deployments usually provide a stable-looking preferred_username and root ownership is also represented by a Maintainer ACL. Avoid changing account identifiers without a planned workspace migration.

Alternatives considered

1. Recommended: typed {realm, subject_type, sub} keys with display attributes resolved separately.
2. Immutable platform user ID mapped to the realm sub by the account service.
3. Continue using normalized email — rejected because email can change and be reassigned.

Component involvement

• Identity/account services expose immutable subject and current display data.
• The backend migrates roots, owners, grants, trash actors, and history actors without duplicating access.
• Oqullus sends canonical member identity while displaying email/name.

Reproduction and verification

In an isolated realm, create and share files, change preferred_username or email for the same sub, sign in again, and verify the same root and ACLs remain effective with updated display data.

Resolution conditions

Close when migration and account-change tests preserve ownership and sharing, and service-principal fallback cannot be mistaken for a user.

Validation and blockers

The claim order and stored string fields are source-confirmed. Identity lifecycle policy and a safe existing-data migration require identity/security review.