TITIP-002 User and identity


Status	Accepted
Version	0.1
Stage	0 — Authority

Purpose

Define the owner account: who may create one, how they sign in for the prototype and the functional MVP, and what the account is not.

Decisions

The owner is the only person who can create vaults, assign recipients, and edit life-check policy. Trusted contacts and recipients have separate portals and separate credentials. They do not share the owner session.
Prototype authentication may be simulated (a named demo user is enough for UC-01), but the contract is the same account the MVP will persist.
Functional MVP authentication must support email, one-time passcode, and server-side sessions. Passkeys may be offered and must not block the MVP if absent.
Account recovery is a threat-model problem, not a convenience feature. Production recovery must be designed in plans/production-readiness.md before it ships. The prototype must not invent a recovery flow that emails vault contents or backup codes stored in Titip.
There is one owner per account in the prototype. Family collaboration (several owners editing one plan) is out of scope until a later spec.

Owner profile

The profile holds the name the product uses in invitations (“Iman menunjuk Anda…”). It must not hold secrets.

Minimum fields are in contracts/schemas/user.schema.json.

Onboarding

The owner-facing order is fixed for the prototype so app and web do not invent different products:

Welcome
  → Create account
  → Security setup
  → Who matters?
  → Trusted contacts
  → Things I want to titipkan
  → Vaults
  → Life check
  → Release rules
  → Review
  → Active

Security setup in the prototype explains what Titip will not store. It does not collect a password vault. Device biometrics, encrypted local cache, and recovery codes are post-prototype.

Session rules

Sessions must be revocable.
A session must be bound to the owner role. It must not be reusable as a recipient access token.
Step-up for recipients is specified in TITIP-009, not here.

Out of scope

Social login as a trusted identity proof of death or incapacity.
Storing government identity numbers “just in case” during signup. Collect identity evidence only for the flow that needs it, under TITIP-009 and TITIP-011.

Acceptance

UC-01 can create an owner and land them in a state where contacts, assets, and a life check can be added.
No owner API returns or accepts a prohibited secret field (ADR-002).