Archived docs. ESS 2.0 has reached end of life.

Release Notes#

Installation and Upgrades#

Starting in version 2.0, ESS provides:

  • inrupt-kustomizer to install or upgrade ESS.

  • Various Kustomize overlays that can act as the base configuration for your deployment.

In addition, improved quality health checks allow for a more robust rolling deploy.

For more information, see:

Pods and WebIDs#

Separate Storage Services and WebID Services#

Starting in 2.0, ESS replaces the LDP service (available in earlier ESS versions) with separate:

With this change, Pods and WebIDs are created independently of each other, and WebIDs are no longer hosted on the Pods. This change allows for multiple Pods per WebID, prevents users from locking themselves out of their Pods, and allows users to obtain their WebID or Pods from alternative providers.

As part of this change:

  • When ESS provisions a new Pod, it creates the Pod with the URL:

    https://storage.{ESS Domain}/{Unique Pod Identifier}/
    
  • When ESS creates a new WebID, ESS creates a WebID of the form:

    https://id.{ESS DOMAIN}/{username}
    

See also:

Security#

Access Control Mechanisms#

ESS 2.0 supports:

  • Identity-Based Access Policies, where access to Pod resources is determined by specific access policies based on agents’ identity, and optionally, the identity of their clients.

  • Access Requests and Grants, where access to Pod resources can be requested and granted (or denied).

To support these mechanisms, ESS also adds UMA Service. This service allows clients to exchange a token or access grant in one format for an access token.

In earlier versions, ESS only supports identity-based access.

For more information, see Authorization/Access Control.

Access Control Policy (ACP) Changes#

In line with the latest Editor’s Draft of Access Control Policy, ACP changes include:

  • ACR (Access Control Resource) is hosted on the Authorization Service. In earlier version, ACRs were located in the Pod.

  • Policies must exist within ACRs. In earlier version, Policies could be stored in a non-ACR resource and just referred to in an ACR.

  • Matchers replaces Rules. Along with the naming change, Matchers require a match in order for the Policy to apply.

  • The noneOf(<Matchers>) expression excludes matches from the allOf(<Matchers>) and anyOf(<Matchers>) expressions; that is, noneOf(<Matchers>) expression acts as a secondary/supplementary filter to the allOf and anyOf expressions

  • Removes match by Group (where Group is identified by its URI/IRI). Instead, specify a matcher with a list of agents.

  • Matchers must be attached to a Policy.

For more information, see Access Control Policy (ACP).

Access Control Client Allow List#

Starting in version 2.0, ESS adds a new configuration option INRUPT_AUTHORIZATION_CLIENT_ID_ALLOW_LIST that determines which applications can interact with Access Control Resource; that is, which applications can read and write access control policies for a resource.

See INRUPT_AUTHORIZATION_CLIENT_ID_ALLOW_LIST.

UMA 2.0 Support#

Starting in 2.0, ESS provides a User Managed Access Grant 2.0 (UMA) service. This service allows clients to exchange a token or credential in one format for an access token.

For more information, see UMA Service.

Access Request/Grant Support#

Starting in version 2.0, ESS supports authorization mechanism based on Access Requests and Grants. With authorization mechanism based on Access Requests and Grants:

  • Agents can request access to resources from the resource owners.

  • The resource owners can either grant or deny the access request.

  • If the access request is granted, the requesting agent can use the access grant to access the requested resource.

For more details, see:

Services#

New Services#

New Service

Notes

Auditing Service

To support auditing activities from ESS services. In earlier ESS version, instead of a separate service, auditing is handled as a named category of Quarkus logging.

For more information on the service, see Auditing Service and Auditing.

Pod Provisioning Service

To manage Pod creation. The service also creates the extended profiles. In earlier ESS version, LDP service handled WebID provisioning as well as Pod provisioning and hosting.

For more information on the service, see Pod Provisioning Service.

See also Separate Storage Services and WebID Services.

Pod Storage Service

To host the created Pods. The service is also responsible for reading and writing the resources stored in the Pod. In earlier ESS version, LDP service handled WebID provisioning as well as Pod provisioning and hosting.

For more information on the service, see Pod Storage Service.

See also Separate Storage Services and WebID Services.

Start Service

To host a default application that acts as the starting point for ESS users. The start application handles the signup or login flow. As part of this flow, the application provisions the user with a WebID and a Pod.

For more information on the service, see Start Service.

See also custom start application.

UMA Service

To support User Managed Access (UMA) Grant 2.0 authorization flow. This service allows clients to exchange a token or credential in one format for an access token that can be used to interact with a Pod resource.

For more information, see UMA Service.

Access Grant Service

To support authorization based on access requests and grants. The new service:

  • Issues access requests and grants, serialized as Verifiable Credentials (VCs).

  • Verifies access requests and grants.

  • Updates the status of access request and grant VCs (e.g., update the status to revoked).

  • Queries for access request and grant VCs and derives a Verifiable Presentation from the matching access request and grant VCs.

For more information, see Access Grant Service.

WebID Service

To create WebIDs and host their corresponding Profile documents.

In earlier ESS version, LDP service handled WebID provisioning as well as Pod provisioning and hosting.

For more information, see Separate Storage Services and WebID Services.

Changed Services#

Changed Service

Notes

Authorization Service

In ESS 2.0, Authorization Service changes include:

  • Hosts Access Control Resources (ACRs) as well as determines the access (based on Access Control Policies). In earlier version of ESS, the Authorization determined the access.

For more information, see

Solid OIDC Broker Service

In ESS 2.0, Solid OIDC Broker Service changes include:

  • Runs from https://openid.{ESS DOMAIN} by default. In earlier version of ESS, the service used https://broker.{ESS DOMAIN} by default.

  • Adds support for static registration of clients.

For more information, see:

Query/QPF Service

In ESS 2.0, Quad Pattern Fragment (QPF) service changes include:

  • Requires the URL of the Pod as a query parameter

  • Requires the data to be indexed.

  • Requires an OIDC token or a UMA 2.0 token to access the service.

For more information, see Quad Pattern Fragment (QPF) service.

Removed Services#

Removed Service

Notes

LDP Service

ESS replaces the LDP service with separate:

See also:

Search Access Service

ESS 2.0 no longer provides search access service. The access service provided a GraphQL endpoint that allowed Pod owners to query a Pod’s access control information.

See Query Service instead.