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
- When a session is created with a finite expiry, the API stores
expireAtEpochMson the session document (and related child documents under that session). - MongoDB's TTL background thread deletes each document whose
expireAtEpochMsis in the past. - Documents without
expireAtEpochMsare 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
expireAtEpochMsfrom 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
expireAtEpochMsfromissuanceSession.expirationTimestampwhen 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 anyorganization_treesdocument 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.
