---
title: "Session Data Ejection"
description: "How the Enterprise API ejects issuer and verifier session PII with MongoDB TTL."
stack: "Enterprise Stack (commercial) — version 1.1.1"
stack_version: "1.1.1"
stack_comparison: https://docs.walt.id/community-vs-enterprise.md
canonical_url: https://docs.walt.id/enterprise-stack/setup/configurations/config-files/session-data-ejection
generated: 2026-10-01
---
# 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.

**Error:**

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

| Service | Document `_t` | TTL source |
|---------|---------------|------------|
| Issuer1 | `stored-issuance-session` | Session `expirationTimestamp` from `expiresInSeconds` |
| Issuer2 | `stored-issuance-session2` | Session `expirationTimestamp` from `expiresInSeconds` |
| Verifier1 | `stored-presentation-session` | Session `expiresInSeconds` / `expires_in_seconds` |
| Verifier1 | Child 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 |
| Verifier2 | `verifier2-session` | Session 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.