3.1 Changelogs

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.

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.

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.

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.