Session Data Ejection (MongoDB TTL)

Issuer and verifier session documents can contain personally identifiable information (PII). The Enterprise API ejects that data using MongoDB's native TTL monitor.

The legacy data-retention feature (data-retention.conf, scheduled purge job, and zero-retention maxAge = "0s" mode) has been removed. Session lifetime is controlled per session via expiresInSeconds / expires_in_seconds (or equivalent offer/session parameters). Upgrade notes: remove data-retention from _features.conf and drop any mounted data-retention.conf.

How it works

  1. When a session is created with a finite expiry, the API stores expireAtEpochMs on the session document (and related child documents under that session).
  2. MongoDB's TTL background thread deletes each document whose expireAtEpochMs is in the past.
  3. Documents without expireAtEpochMs are never deleted by TTL (explicit infinite / never-expire sessions).

Covered document types

ServiceDocument _tTTL source
Issuer1stored-issuance-sessionSession expirationTimestamp from expiresInSeconds
Issuer2stored-issuance-session2Session expirationTimestamp from expiresInSeconds
Verifier1stored-presentation-sessionSession expiresInSeconds / expires_in_seconds
Verifier1Child docs under the presentation session (stored-token-response, stored-verification-result, stored-presentation-request, stored-presentation-definition, stored-create-presentation-session-request, stored-verification-information)Same expireAtEpochMs as the parent session
Verifier2verifier2-sessionSession expiration date

Not short-TTL'd

session-credential-status-index maps an issuance session to a bit position in a status list. It is intentionally not given a short TTL so revocation can keep working after the issuance session document itself has been ejected.

Controlling session lifetime

Issuer1 / Issuer2

Set expiresInSeconds on the issuance / offer request (default is typically a few minutes).

Verifier1

Set expires_in_seconds when creating a presentation session.

Verifier2

Session expiry is taken from the verification session configuration; either expiration_duration or expiration_date.

Migrations and existing data

On upgrade, migration V0013:

  • Copies expireAtEpochMs from living Verifier1 parent sessions onto children that were missing it
  • Deletes orphan Verifier1 child documents whose parent presentation session was already TTL-deleted
  • Backfills missing Issuer1 / Issuer2 expireAtEpochMs from issuanceSession.expirationTimestamp when that expiry is finite

New installations get the TTL index from earlier migrations (V0006 / V0008).

Operational notes

  • TTL deletion is performed by MongoDB (typically within about a minute of expiry, depending on the TTL monitor interval). It is not an application cron.
  • API keys and other resources may also use expireAtEpochMs; the same index applies to any organization_trees document that sets the field.
  • For compliance planning, treat session PII lifetime as at most the configured session expiry (plus MongoDB TTL lag), not a separate retention window.
Last updated on August 18, 2026