TITIP-009 Recipient verification
Status Accepted
Version 0.1
Stage 0 — Authority

Purpose

Define how a recipient, and only that recipient, comes to see an authorised vault after a real release is approved. The contract exists now so app, web, and backend do not invent a “magic link with the PDF attached” later.

The prototype simulates the result. It does not run this flow against real people. Alpha stage 4 implements it (plans/alpha.md).

Flow

Recipient receives notice
  → opens secure portal
  → verifies email or phone
  → identity step-up
  → accepts disclosure statement
  → receives vault-specific access
  → access expires

Decisions

  1. The notice channel (email, SMS, later WhatsApp) must not contain instruction text, document bytes, or a long-lived URL.
  2. The link must be:
    • short-lived (prototype contract: expires in 60 minutes, single continuation into the portal session)
    • single-purpose (this case, this recipient)
    • revocable by a reviewer or by global hold
    • bound to the recipient record, not transferable
  3. Verifying email or phone proves channel control. It is not sufficient for vault access. Step-up must be a second factor defined before alpha implementation (identity provider or equivalent). Until that control is accepted in an ADR addendum, real DELIVERED stays disabled.
  4. The disclosure statement must say: access is limited to items the owner assigned; Titip is not a law firm or executor; access is logged; access can expire and be revoked.
  5. The resulting token must list vault ids. Vault service must reject any id not on that list. Expiry must be enforced server-side. Default access window for the first real release is 7 days, renewable only by a new reviewer-approved token, not by the recipient clicking “remember me”.
  6. Every view and download must emit an audit event with recipient id, vault id, content version, and time.
  7. Revocation must invalidate unused tokens immediately. Already-rendered client caches are out of scope for prototype; production readiness requires a control for that before launch.

Holds

If the case says HOLD for a vault, verification must not unlock it, even if the same recipient has another RELEASABLE vault. The age rule on the daughter’s message is the reference case.

Impersonation

Recipient impersonation is an expected abuse case. Binding the token to a verified recipient identity, refusing shared links, and auditing access are mandatory. A forged death notice to support is not a verification path. Staff must not have a button that marks a recipient verified without the step-up record.

Acceptance