> For the complete documentation index, see [llms.txt](https://docs.inrupt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.inrupt.com/ess/releases/changelog.md).

# 3.x Changelogs

## v3.3.0

Released: 2026-09-10

### New features

#### **Activity Log**

ESS 3.3.0 adds the [Activity Log](/ess/services/service-platform-management/activity-log.md), a new API on the Platform Management service that lets applications retrieve recent activity for an authenticated user's account. It can be used to build user-facing features such as an in-app activity feed. Activities are presented using the W3C Activity Streams format and cover six event categories: Resource, Access, Account, Notification, DataView, and Purge.

See [Activity Log](/ess/services/service-platform-management/activity-log.md) for full documentation.

#### **Account Audit Events**

The Platform Management service now emits audit events for account lifecycle operations: **`account-created`**, **`account-updated`**, **`admin-account-created`**, **`admin-account-activated`**, and **`admin-account-deprovisioned`**. These give operators visibility into account provisioning and administrative account actions alongside existing resource and access audit events.

#### **Subscription Audit Events**

The Notification service now emits audit events when WebSocket and webhook subscriptions are created or deleted — **`subscription-created`** and **`subscription-deleted`**. These events are recorded in the [ESS Audit](/ess/services/service-auditing.md) stream, giving operators visibility into subscription lifecycle activity.

#### **Transactional Outbox for Audit Events**

All services that publish audit events have migrated from a direct audit producer to a transactional outbox pattern. Audit events are now written to the database within the same transaction as the operation they record, then delivered asynchronously. Delivery is retried until it succeeds, so a temporary messaging outage does not prevent an audit event from being delivered.

#### **Richer Audit Events**

Audit events now include additional structured context:

* **Storage audit events** include the canonical storage URI, making it easier to correlate events across path-based and canonical resource identifiers.
* **Verifiable Credential audit events** include the grantee as a structured `target` field, providing direct visibility into who was granted access without requiring a secondary lookup.

### Changed

#### **Container Timestamp Audit Event**

Container timestamp updates triggered by changes to child resources now emit **`resource-touched`** rather than **`resource-updated`**. Consumers that relied on **`resource-updated`** to detect child resource activity on a container should subscribe to **`resource-touched`** instead. See [Auditing](https://docs.inrupt.com/security/auditing/#audit-events) for the full event list.

#### **Access Grant Read Operations Auditing**

Audit events for the Access Grant Service's **`/query`** and **`/verify`** endpoints are now gated by a new configuration property, [**`INRUPT_VC_AUDIT_READ_OPERATIONS_ENABLED`**](/ess/services/service-access-grant.md#inrupt_vc_audit_read_operations_enabled), which defaults to **`false`**. After upgrading, those endpoints no longer emit **`access-credential-queried`**, **`access-grant-verified`**, **`access-request-verified`**, **`access-denial-verified`**, or the associated **`request-authorized`** events until an operator opts in.

All other Access Grant Service endpoints — including **`/issue`**, status revocation via **`/status`**, and the **`GET /vc/{id}`** and **`GET /status/{id}`** read operations — remain unconditionally audited.

### Removed

#### **Service Lifecycle Audit Events**

The **`service-started`** and **`service-shutdown`** audit events are no longer emitted.

## v3.2.0

Released: 2026-07-24

### New features

#### **Search Service**

ESS 3.2.0 introduces an optional [Search Service](/ess/services/service-search.md) that enables full-text and semantic search over Pod content. It is deployed as four cooperating microservices: Search (query API), Ingest (indexing pipeline), Embedding (ML vector generation), and OCR (text extraction for PDFs and images). Content is indexed automatically as Pods change. Hybrid, keyword-only, and semantic search modes are supported.

See [Search Service](/ess/services/service-search.md) for full documentation.

## v3.1.0

Released: 2026-06-29

### New features

#### **Database Credential Separation (DML/DDL Split)**

ESS services that use PostgreSQL now support separate database credentials for schema migrations (DDL) and application runtime (DML). DDL credentials are used by Flyway at startup to run schema migrations. DML credentials are used at runtime for application queries and are restricted to `CONNECT`, `USAGE`, `SELECT`, `INSERT`, `UPDATE`, and `DELETE` on the `public` schema only.

Two new environment variables are added to each affected deployment:

| Variable                  | Purpose                                     |
| ------------------------- | ------------------------------------------- |
| `QUARKUS_FLYWAY_USERNAME` | Username for Flyway schema migrations (DDL) |
| `QUARKUS_FLYWAY_PASSWORD` | Password for Flyway schema migrations (DDL) |

The existing `QUARKUS_DATASOURCE_USERNAME` and `QUARKUS_DATASOURCE_PASSWORD` variables continue to control the runtime database connection (DML).

The following services are affected:

| Service                | Deployment / Job                       |
| ---------------------- | -------------------------------------- |
| Authorization          | `authorization-acp`                    |
| Notification           | `ess-notification`                     |
| OpenID                 | `ess-openid`                           |
| WebID                  | `ess-webid`                            |
| Verifiable Credentials | `ess-vc-issuer`                        |
| Platform Management    | `ess-platform-management`              |
| Purger                 | `ess-purger-service`, `ess-purger-job` |
| Storage                | `ess-storage-postgres-migration`       |

In the default configuration, both sets of credentials reference the same Kubernetes secret. No database changes or new users are required to upgrade. The credential split is opt-in.

To activate separate DML and DDL users:

1. **Provision database users.** Create dedicated DML and DDL PostgreSQL roles for each database. DDL roles should be granted membership in the `postgres` role. DML roles should be granted only `CONNECT`, `USAGE`, and row-level DML permissions (`SELECT`, `INSERT`, `UPDATE`, `DELETE`) with matching default privileges for future tables and sequences.
2. **Store credentials.** Create Kubernetes secrets containing the DML and DDL credentials for each service.
3. **Update Kustomize overlays.** Patch the affected deployments so that:
   * `QUARKUS_DATASOURCE_USERNAME` / `QUARKUS_DATASOURCE_PASSWORD` reference the DML credentials secret
   * `QUARKUS_FLYWAY_USERNAME` / `QUARKUS_FLYWAY_PASSWORD` reference the DDL credentials secret
4. **Roll out.** Restart the affected deployments. Flyway will connect with the DDL credentials to run any pending migrations, and the application will use the DML credentials for all runtime queries.

{% hint style="info" %}
If you manage your infrastructure with Terraform, the new `rds-users` module automates user provisioning, credential storage in AWS Secrets Manager, and optional A/B password rotation.
{% endhint %}

### Infrastructure updates

#### **Updated Docker Base Images**

All service images are rebuilt with the latest Red Hat UBI base images, incorporating recent security patches.

### Service versions

ESS release versions (e.g., 3.1.0) identify the platform as a whole — the tested, supported combination of all services and infrastructure. Individual services are versioned independently based on their own release cadence. A service whose version number differs from the ESS release version has not necessarily changed between ESS releases; the table below lists the exact image tag deployed for each service in this release.

| Service                       | Version |
| ----------------------------- | ------- |
| enterprise-storage            | 3.0.2   |
| enterprise-openid             | 3.0.2   |
| enterprise-authorization      | 3.0.2   |
| enterprise-async-notification | 3.0.2   |
| enterprise-audit              | 3.0.2   |
| enterprise-webid              | 3.0.2   |
| enterprise-vc                 | 3.0.2   |
| enterprise-platform           | 3.0.2   |
| enterprise-start              | 3.0.2   |
| enterprise-mcp                | 2.0.2   |

## v3.0.0

Released: 2026-05-27

### New features

#### **Native Identity Provider Support**

ESS now supports direct integration with external OIDC-compliant Identity Providers. Clients authenticate with their existing IdP and exchange the resulting token for an ESS Access Token via a token exchange endpoint hosted by the Platform Management service. The ESS OpenID Broker is no longer required as an intermediary.

#### **Identifiers**

Permanent, globally unique identifiers for storages, resources, agents, and clients. Resources are now accessible via canonical URIs (`{storage-id}/sc/{resource-id}`) alongside path-based URIs (`{storage-id}/sp/{resource-path}`). ESS identifiers mitigate PII leakage and provide durable references for Access Grants, notifications, and AI agent context.

#### **Environment Isolation**

Each ESS service can operate within its own named PostgreSQL database schema. This provides deployment flexibility — all services can connect to a single database instance, or separate database instances can be used for each service.

#### **Unified User Provisioning**

All user provisioning — including account creation, WebID management, and storage allocation — is handled through the Platform Management service. New user registration APIs, identity mapping admin APIs, and agent account endpoints.

### Breaking changes

#### **UMA Service Removed**

The UMA service has been removed. Access Grants now serve as receipts — once the resource owner approves an Access Grant, the recipient can retrieve the granted resources directly using their ESS Access Token. ESS checks the grant server-side, so no UMA negotiation or additional token exchange is needed. This simplifies the access flow and reduces client code complexity. Remove all UMA token exchange logic from client applications.

#### **Query/QPF (Fragments) Service Removed**

The Query/QPF service has been removed. These capabilities are being replaced with new search capabilities.

#### **WebSocket Notification Service Removed**

The WebSocket Notification Service has been removed. Use the Notification Delivery Service.

#### **Notification Gateway Service Removed**

The Notification Gateway Service has been removed.

#### **Wallet Service Removed**

The Wallet Service has been removed.

#### **Provisioning Flow Changed**

All user provisioning (accounts, WebIDs, and storage) is now handled through the Platform Management service. The Pod Provisioning Service and WebID Service endpoints are no longer called directly by clients. Update start applications and onboarding flows to use the [Platform Management API](/ess/services/service-platform-management/platform-management-api.md).

#### **Authentication Flow Changed**

Clients must now authenticate with an external Identity Provider and exchange the resulting ID token for an ESS Access Token via the token exchange endpoint on the Platform Management service. The ESS OpenID Broker is no longer required as an intermediary.

#### **Access Grants Decoupled from ACP**

Access Grants no longer require ACP policies to enable their use. Once a resource owner approves an Access Grant, the recipient can access the resource directly. The `INRUPT_AUTHORIZATION_DEFAULT_ACR_ACCESS_GRANTS_ALLOWED_MODES` configuration and the VC Matcher policies in the initial Pod ACR are no longer needed.

#### **Canonical URIs Required for Access Grants and Notifications**

Access Grant issuing and notification subscriptions must use canonical resource URIs (the `/sc/` form). This is so access is more stable and secure. Path-based URIs continue to work for direct resource access.

#### **Audit Events Updated**

Audit events now include identifiers for all referenced resources.