Release Notes

ESS 3.1.0 (Released 2026-06-29)

ESS 3.1.0 introduces least-privilege database credential separation for PostgreSQL-backed services.

Database Credential Separation (DML/DDL Split)

ESS services that use PostgreSQL now support separate database credentials for schema migrations and application runtime:

• DDL credentials are used by Flyway at startup to run schema migrations. These users are granted the PostgreSQL master role so that migrated objects remain owned by the postgres user.

• DML credentials are used at runtime for application queries. These users are restricted to CONNECT, USAGE, SELECT, INSERT, UPDATE, and DELETE on the public schema only.

This separation follows the principle of least privilege: the credentials used during normal operation cannot modify the database schema, reducing the blast radius of a compromised credential. In the default configuration, both sets of credentials reference the same Kubernetes secret — no changes are required to upgrade. The credential split is opt-in.

For details on enabling credential separation, see the 3.x Changelogs.

ESS 3.0.0 (Released 2026-05-27)

ESS 3.0 is a major release that introduces native Identity Provider support, permanent resource identifiers, simplified Access Grant flows, and environment isolation.

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

ESS assigns permanent, globally unique identifiers to storages, resources, agents, and clients. Resources are now accessible via canonical URIs ({storage-id}/sc/{resource-id}) in addition to path-based URIs ({storage-id}/sp/{resource-path}). Access Grant issuing and notification subscriptions must use canonical URIs so that access is more stable and secure.

Simplified Access Grant Flow

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. Additionally, Access Grants are now fully independent of ACP — no VC Matcher policies or ACP enablement configuration is required. This simplifies the access flow, reduces client code complexity, and eliminates a common source of hidden authorization failures.

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. The Pod Provisioning Service and WebID Service endpoints are no longer called directly by clients.

Removed Services

The following services have been removed in ESS 3.0:

• UMA Service: Replaced by simplified Access Grant flow with direct resource access

• Query/QPF (Fragments) Service: Being replaced with new search capabilities

• Notification Gateway Service: Removed

• WebSocket Notification Service: Removed; use the Notification Delivery Service

Changelogs

For changelogs, see 3.x Changelogs.