# Release Notes

## 2.3

*ESS 2.3.0 Released 2024-12-12*

### Error Response Enhancements

Starting in 2.3, ESS services can provide more information in their HTTP error responses. Specifically, the ESS services follow [**RFC 9457 (Problem Details for HTTP APIs)**](https://datatracker.ietf.org/doc/html/rfc9457.html) and may include the fields specified in the RFC:

```
{
  "status": <status code>,
  "title":  "<summary>",
  "detail": "<additional description/details of the error>",
  "instance": "<OpenTelemetry Span Id>"
}
```

For UMA and OIDC Broker services, they continue, as in earlier versions, to follow [**RFC 6749 (OAuth 2.0)**](https://datatracker.ietf.org/doc/html/rfc6749.html#section-5.2), and the new [**RFC 9457**](https://datatracker.ietf.org/doc/html/rfc9457.html) fields are added to their error response.

```
{
  "status": <status code>,
  "title":  "<summary>",
  "detail": "<additional description/details of the error>",
  "instance": "<OpenTelemetry Span Id>",
  "error": "<error code per RFC6749>",
  "error_description": "<optional error description per RFC6749>",
  // ...
}
```

For error responses to browser requests, the ESS error pages (**`text/html`** media type) display the new information.

For other error responses:

* For services that only follow [**RFC 9457**](https://datatracker.ietf.org/doc/html/rfc9457.html), the error responses return as **`application/problem+json`** media type.
* For UMA and OIDC Broker services, [**RFC 6749**](https://datatracker.ietf.org/doc/html/rfc6749.html) takes precedence over [**RFC 9457**](https://datatracker.ietf.org/doc/html/rfc9457.html), and as such, the error responses return as **`application/json`** media type.

For more information, see Error Responses.

### Pod Deletion via Purger Application

Starting in 2.3, ESS includes a Purger CLI application which can be used as part of a workflow for deleting user data. This can help organizations adopting ESS to comply with legislative requirements, such as GDPR/CCPA and the right to have personal data deleted.

For more information, see Purger Application.

### Access Grant Query Improvements

Starting in 2.3, ESS includes a **`/query`** endpoint in the Access Grants Service. This provides an optimized mechanism to search and filter [Verifiable Credentials (VCs)](https://docs.inrupt.com/reference/glossary#verifiable-credential) which are the serialized form of access requests and grants.

This endpoint replaces the **`/derive`** endpoint, which is now deprecated.

For more information, see /query Endpoint.

### 3rd-party Dependency Updates

Starting in 2.3, various 3rd-party dependencies used by ESS have been updated. Key dependency upgrades include:

#### Java 21

Starting in 2.3, ESS has upgraded to Java 21.

#### PostgreSQL 17

Starting in ESS 2.3, the image reference to PostgreSQL, in Inrupt’s **non**-production overlay (i.e., the **`standalone`** overlay), has been upgraded from version 15 to 17. Customers who are using Inrupt’s **`standalone`** overlay need to reset their state or [upgrade Postgres](https://www.postgresql.org/docs/current/upgrading.html).

This change does **NOT** affect those deployments that use the production overlay (i.e., the **`scalable-cloud`** overlay). Customers using the **`scalable-cloud`** overlay use their own stateful services and are not impacted by the change.

#### Kafka 3.8

Starting in 2.3, ESS has upgraded to Kafka 3.8 in the `standalone` overlay.

#### Keycloak 26

Starting in 2.3, ESS has upgraded to Keycloak 26 in the `standalone` overlay.

## Patch Releases

### 2.3.1

*Released 2025-01-10*

**Access Grant Service**

Makes the Access Grant issuer backwards compatible whilst still allowing clients to use the newer JSON-LD context.

### 2.3.2

*Released 2025-01-14*

**Access Grant Service**

Makes the Access Grant derive backwards compatible so that a client can request a list of credentials using both the older and newer JSON-LD context.

This change will require updates to client libraries to ensure that applications can issue credentials using the latest version of the context (which is required for some features such as linking grants to requests). Updating client libraries will also ensure that credentials which have been issued with that latest context will be sent back to the client. Updates are not required for any other reason.

* JavaScript Client Libraries - Users of **`@inrupt/solid-client-access-grants`**, version 3.1 upwards, **MUST** upgrade to version 3.2.1. Users of older versions **SHOULD** also upgrade.
* Java Client Libraries - Users **MUST** upgrade to version 1.3.1.

### 2.3.3

*Released 2025-03-24*

**Solid OIDC Broker Service**

The Broker Service now supports [Auth0](https://auth0.com/) as a backend OpenID Provider.

This change is transparent to client libraries, and no client upgrades are required.

### 2.3.4

*Released 2025-04-28*

**Solid OIDC Broker Service**

The Broker Service can be configured to allow trusted clients to bypass the approval page, providing a better experience for users. If the configuration is not used, then the existing behavior is unchanged and users will be presented with the approval page when offline access is requested.

The service will omit null fields from JSON responses rather than serialize them.

**Deployment Changes**

The JVM image included in the ESS base has been upgraded to UBI 9. The JDK version has not been changed and this should have no noticeable impact on a deployment.

The Keycloak Kubernetes deployment base, used in Standalone deployments, has been improved to provide better service stability and to enable health checks.

### 2.3.5

*Released 2025-06-26*

**Message Security Enhancement**

Encryption for messaging was enhanced with an update to the key derivation algorithms. Existing messages remain fully accessible during a migration of the encryption standard.

### 2.3.6

*Released 2025-07-09*

**All Services**

Metrics and health status endpoints are now available within the ESS cluster on port 9000.

## Changelogs

For changelogs, see 2.3 [Changelogs](https://docs.inrupt.com/ess/2.3/releases/changelog).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.inrupt.com/ess/2.3/releases.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
