Access Requests and Grants

Inrupt's Enterprise Solid Server (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 resources to access, the purpose the data will be used, 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.

1. 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.

Note:

• 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 ).

Enable Access Grant Usage (ACP)

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 ACP that includes:

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

• The allowed access modes ( Read , Write , Append ).

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.

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)

ESS provides Authorization Management Component (AMC) as a reference component to demonstrate best Engineering and UX practices around managing Access Requests and Grants.