Users Schema

Purpose

• Supports login and verification.
• Separates platform identity from document facts stored in data_pool modules.
• Allows signing and authoring permissions without overloading document data.
• Before sign-in, each browser has one anonymous user: no email, its browserClientId recorded, minted the first time that browser creates a folio and reused after (GB-309). It holds the owner rows in folioUsers for what that browser created.
• A user is not the same as a document party. A party, willmaker, executor, attorney, or client is ordinary document data unless that person also authenticates as a platform user.

Relationships

• A users row holds roles on Folios through folioUsers, and is named in folios.owner for the folios it created.
• A users row owns many authSessions over time, each tied to one unified documents row once the drafting session has selected or created a document.
• authStatus transitions are driven by the auth module during the interview — see Auth Flow. A user is verified once and then recognized on subsequent sessions by email or phone.
• Party facts do not live on users. They live in a document's data_pool module and may describe the authenticated user, another client, or any other person or organisation named in the document.

Fields

Example document

An anonymous user, before sign-in:

{
  "key": "user_01k5z3m8q2x7c9v4b6n1p0r2st",
  "browserClientId": "browser_9f2c…"
}

A verified user:

{
  "key": "user_01HV8XQZK4J9R9W3M6T4M2RUS1",
  "email": "jane.smith@example.com",
  "phone": "+61400000000",
  "authStatus": "verified",
  "signingKeyReference": "keys/user_01HV8XQZK4J9R9W3M6T4M2RUS1/signing.pub"
}