Access Requests and Grants

Added in version 2.0.

Starting in version 2.0, ESS supports an authorization mechanism based on access requests and grants. With access requests and grants:

1. An agent sends an access request to the resource owner. In ESS, the access request is serialized as a VC. This request includes the specific access mode (e.g. Read, Write, Append), the resource(s) to access, etc.

2. The resource owner decides to deny or grant the access request:

   • For an approved request, ESS creates an access grant with an approved status.

   • For a denied request, ESS creates an access grant with a denied status.

   In ESS, the access grant is serialized as a VC, and the resource owner can revoke the access grant in the future.

3. If the requesting agent has an approved access grant, the requesting agent can exchange the access grant for an access token in order to access the resource.

Starting in version 2.1:

• An access request for a Container, by default, also applies to the Container’s descendants, unless explicitly specified otherwise in the request (See inherit: false).

• An access grant for a Container, by default, also applies to the Container’s descendants, unless explicitly specified otherwise in the grant (See inherit: false).

In the previous version, access request/grant applied only to the explicitly stated resource or resources in the access request/grant, regardless of whether the resource is a Container, an Resource Description Framework (RDF) Resource, or a Non-RDF Resource.

Enable Access Grant Usage (ACP)

Note

Starting in 2.2, ESS enables the use of access grants by default. Specifically, when ESS creates a new Pod, ESS creates default policies that enable the use of access grants for that Pod. See Initial ACP Policies for details.

ESS uses Access Control Policy (ACP) to define the policies that determine access to Pod’s resources. To enable the use of access grants for a resource, the resource must have an Access Control Policy (ACP) that includes [1]:

• A VC Matcher Type of http://www.w3.org/ns/solid/vc#SolidAccessGrant

• The allowed access mode(s) (Read, Write, Append).

Important

The policy only enables the use of access grants on that resource for the allowed access modes. To determine the access for an agent using an access grant, ESS uses the intersection of:

• The allowed access specified by the resource’ ACP, and

• The granted access specified in the access grant for that resource.

For example:

• A resource has an ACP that enables the use of access grants for Read access.

• An agent has an access grant for that resource that allows Read and Write access.

Then, the agent can use the access grant to Read the resource only. The agent cannot use the access grant to Write the resource, even though the access grant specifies both Read and Write access.

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

[1]

The Policy can include additional Matchers; for example, an Agent Matcher to enable access grant use for a specific Agent.

Access Grant Effective Period

An active (i.e., not revoked) access grant is effective:

• Starting from its issuanceDate to its expirationDate, and

• While its credentialSubject.id (the grantor) remains a resource owner.

Services to Support Access Requests and Grants

To support access requests and grants, ESS provides the following services:

• Access Grant Service. The Access Grant service is responsible for issuing, verifying, and revoking Verifiable Credentials.

• User Managed Access Grant 2.0 (UMA) service to exchange the access grants for an access token.

• Authorization Service to manage the ACPs.

Authorization Management Component (AMC)

Added in version 2.2.0.

ESS provides Authorization Management Component (AMC) for managing access requests and grants. For more information, see Authorization Management Component (AMC).

See also Recommendations for Applications.