> 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.2 Changelogs

## 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.