ADR-026: Privacy-First Applicant Portal (Client-Encrypted Drafts + Redis-Primary Sessions)

The credential and the encrypted draft are minted at draft-start under a reserved application_id (a UUID that does not yet exist in the applications table). The applications row — whose household_id, submitted_by, programs_requested, and submission_channel columns are NOT NULL and unknown until the form is filled — is created only at finalize, using that same reserved id. Drafts therefore never enter the applications table, so there is no draft application status and no worker-queue filtering (workers never see drafts).

Because no applications row exists during the draft window, the credential tables cannot carry a foreign key to it; their REFERENCES applications(id) is dropped. Referential integrity is enforced by construction (finalize always creates the row; the reaper deletes everything for an unfinalized reserved id), not by a database FK.

A new application_drafts table in canopy-applications:

with an index on expires_at. The WASM client encrypts each step’s partial payload and PATCH`es the ciphertext; the server stores and serves the blob blind. `expires_at is the sliding deadline last_saved_at + 30 days, rewritten on every save; the reaper deletes WHERE expires_at < now(). kdf_salt is the per-draft Argon2id salt — non-secret and persisted so a cross-session resume re-derives the same key.

Argon2id(passcode, kdf_salt) → 256-bit key → XChaCha20-Poly1305 AEAD (a fresh nonce per save), consistent with ADR-017’s ChaCha20-Poly1305 choice. enc_version provides crypto agility. The client-side crypto is WebAssembly (argon2 + chacha20poly1305 compiled to wasm32) — it needs no eval and no new CSP directive ('wasm-unsafe-eval', already permitted for WASM instantiation, covers it); it does not threaten the strict-CSP gate.

create-draft mints the reserved application_id (UUID) plus the HH-[a-f0-9]{8} code (bounded collision-retry on the application_id_codes.code UNIQUE constraint) plus the NNNN-NNNN-NNNN passcode (twelve uniform-random digits; format per ADR-008 Amendment 3). It writes application_drafts, application_id_codes, and passcode_hashes (the passcode argon2id-hashed) — none foreign-keyed to applications — and returns {application_id, code, raw passcode} to the client over TLS. The client derives the draft key from the passcode (with a distinct KDF salt context) and encrypts. The server discards the raw passcode, persisting only the one-way hash and the ciphertext.

The raw passcode is held in client memory / sessionStorage only (see key handling in Consequences) and is not displayed through the flow. It is revealed on the Submitted screen at finalize, or earlier if the applicant explicitly chooses "continue later." One credential serves two roles: the draft-encryption-key source and the post-submission login.

Submit = the client decrypts the full draft and POST`s plaintext to a `finalize endpoint. canopy-applications creates persons → household → members → income and the applications row with id set to the reserved application_id (status submitted). Today’s create path always generates a fresh id (services/canopy-applications/src/store/mod.rs, ApplicationId::new()), so finalize needs a create path that accepts an explicit id.

The applications INSERT and the application_drafts DELETE MUST be one canopy-applications transaction. The no-orphan guarantee depends on it: a "create, then separately delete" sequence opens a window in which the reserved id is in neither table. The finalize path takes a SELECT … FOR UPDATE row lock on the draft so it serialises against the reaper (§6). The credentials are kept (they become the submitted application’s login). The server sees plaintext PII only here.

(The persons/household writes span canopy-persons, a separate service and database per ADR-001; that cross-service ordering is the pre-existing orchestration concern, not introduced by this ADR. The single-transaction guarantee above is specifically the intra-canopy-applications applications-INSERT + draft-DELETE pair.)

A background job deletes application_drafts WHERE expires_at < now() and, in the same step, the matching application_id_codes and passcode_hashes rows — explicit ordered deletes, not ON DELETE CASCADE. (Finalize must delete the draft while keeping the credentials, so a draft → credential cascade would be wrong.) The reaper serialises with finalize on the draft row: it takes the same SELECT … FOR UPDATE lock and re-checks expires_at inside its transaction, so it cannot delete the credentials of a draft whose finalize is in flight (which would leave a submitted application whose login was reaped). There is no draft application status and no worker-queue filtering.

The authenticated session is an opaque 256-bit CSPRNG token. Redis holds session:{token_hash} → {application_id, code, device_id, flow_kind, expires_at} (the token is hashed at rest; the raw token lives only in the cookie). The TTL is flow_kind-derived (30 min apply/recovery/renewal · 2 h steady-state · 15 min kiosk); DEL is the server-side kill-switch; a device:{id} secondary index drives the rate-limit cascade. The session is minted at draft-start and tied to the reserved application_id. There is no anonymous PostgreSQL session — pre-draft browsing (the Welcome screen) is stateless.

Hard prerequisite: a noeviction Redis session keyspace must exist before Redis-primary sessions ship. The devstack Redis is configured maxmemory-policy allkeys-lru (a cache), which would silently evict live sessions; the session keyspace must be a separate Redis logical database (or instance) with maxmemory-policy noeviction. The worker portal is unchanged. The portal is Postgres-free: no canopy-api / canopy-db / canopy-mq, no sqlx, no migrations — it owns only Redis (sessions + rate-limit counters).

Session security events (mint / revoke / kill-switch) must reach canopy-security, which today ingests audit only via the RabbitMQ wildcard subscriber and exposes only read / export / archive routes. The portal has no broker, so this requires a net-new best-effort POST /v1/security/audit/ingest on canopy-security (service-token auth per ADR-019). It is fire-and-forget / non-blocking: a canopy-security outage must never break the applicant flow, so failures are logged and dropped, not retried into the request path.

The recovery flow is a safety-critical intimate-threat defense (the dominant threat is the person who knows the applicant — partner, ex, family — not a stranger; see the design applicant-portal design ref §3.4-3.8). It applies to submitted applications only: a reserved-id draft (no applications row) is never recoverable.

The security boundary is not the challenge answers. Per applicant-portal design ref §3.7 the challenge inputs "are not a security boundary on their own." The boundary is the Application-ID gate (HH-… — random hex an intimate threat is unlikely to have memorised) + a date-of-birth second factor (verified against the submitter’s canopy-persons record) + a confidential-case block + a 24-hour delayed reveal + a one-tap kill-switch + a side-channel notification to the application-time contact (the contact on file at original application, never a recently-changed — possibly attacker-controlled — one) + the rate-limit cascade. A CAPTCHA gate on the /recover initiate step is defense-in-depth against wide-net automated guessing; it ships as a config-driven verifier abstraction (noop default) with the real provider deferred (see the Plan 3 plan + issue #663).

Confidentiality flag. applications.confidentiality ∈ {standard, confidential, address_confidential, both}. confidential and both disable self-serve recovery (the applicant is routed to phone/in-person verification, applicant-portal design ref §3.8); address_confidential is about address echoing (ACP routing), not recovery access, so on its own it does not disable self-serve. The recovery Lookup still accepts input for confidential cases and the server short-circuits to a confidential_blocked outcome after the App-ID matches — hiding the affordance would itself leak case existence; this is a deliberate, accepted disclosure that routes protected cases to safe human verification, and the attempt is flagged for worker visibility.

Kill-switch and case-lock. The "this wasn’t me" link cancels the pending recovery and sets a durable applications.recovery_locked boolean (a worker must clear it before self-serve is available again). It is a boolean, not a new application-status value — a recovery_locked status would pollute every status consumer. Existing logged-in sessions are not invalidated by an initiation.

Oracle safety. POST /v1/applicants/recover/initiate always returns 200 with the outcome in the body (pending / confidential_blocked / challenge_failed), never in the status code, so the endpoint is not a case-enumeration oracle: an unknown code and a wrong date-of-birth both return the uniform challenge_failed.

Event/secret hygiene (extends ADR-004). The recovery outbox events (application.applicant.recovery_{initiated,killed,confidential_blocked}) carry IDs + the reveal timestamp only. The kill-switch token (a capability secret) and the notify contact are deliberately kept off the broadcast bus + the security audit log — the notification subscriber reads them from the recovery_pending row by recovery_id via a service-token call.

This subsection is the ADR home for the recovery/confidentiality model that the canopy-applications recovery artifacts (store::recovery, api::recovery, the recovery_pending + gate-column migrations, the Confidentiality enum, the recovery contracts) cite.