Access Control Policy (ACP)

ESS uses Access Control Policy (ACP) to manage access to Pod resources. [1] With ACP, Pod owners can define Policies that determine access for their Pod’s resources.

Policies

Policies determine access for Pod resources. A policy statement consists of:

• Matcher statements that specify conditions that must be satisfied for the Policy to take effect.

• Access mode statements that specify which access modes are allowed and/or denied to the agent(s) satisfying the Matcher statements.

If

< allOf | anyOf > (Matcher(s)) evaluates to true, AND

< allOf | anyOf | noneOf > (Matcher(s)) evaluates to true, AND

…

Then

<allow (AccessMode(s)) | deny (AccessMode(s)) | allow (AccessMode(s)) AND deny (AccessMode(s)) >

Important

The noneOf() expression excludes matches from the allOf and anyOf expressions; i.e., you can use the noneOf expression to refine the allOf and anyOf matches.

Because the noneOf() expression acts as a secondary/supplementary filter to the allOf and anyOf expressions, a policy statement with only a noneOf(<matchers>) condition cannot be satisfied.

Matcher Statements

< allOf | anyOf > (Matcher(s)) evaluate to true, AND

< allOf | anyOf | noneOf > (Matcher(s)) evaluates to true, AND

…

Matchers

Matchers specify the conditions under which the Access Policy applies.

ESS supports the following types of Matchers:

Agent Matchers	To match agents by specific WebID(s). To match any authenticated agent. To match any agent.
Client Application Matchers	To match by specific Client ID(s). To match any client application. Note To use Client Application Matchers, the Policy must also specify an Agent Matcher.
Verifiable Credentials Matchers	To match by Verifiable Credential(s) type; e.g., match VC type http://www.w3.org/ns/solid/vc#SolidAccessGrant.

allOf, anyOf, noneOf Operators

A policy specifies its matchers in allOf(), anyOf(), and noneOf() operator expressions.

allOf(<matchers>)	Evaluates to true if all of its listed matchers evaluate to true.
anyOf(<matchers>)	Evaluates to true if any of its listed matchers evaluate to true.
noneOf(<matchers>)	Evaluates to true if none of its listed matchers evaluate to true.

Important

The noneOf() expression excludes matches from the allOf and anyOf expressions; i.e., you can use the noneOf expression to refine the allOf and anyOf matches.

Because the noneOf() expression acts as a secondary/supplementary filter to the allOf and anyOf expressions, a policy statement with only a noneOf(<matchers>) condition cannot be satisfied.

Access Mode Statements

<allow (AccessMode(s)) | deny (AccessMode(s)) | allow (AccessMode(s)) AND deny (AccessMode(s)) >

Access Modes

Access Modes describe the permissions that can be granted or denied. The available modes are:

Access Mode	Description
Read	Permission to view/retrieve a resource. See also CRUD Operations and Access Modes.
Write	Permission to create a resource, update the content of a resource, and delete a resource: Tip To create a resource, you must have Write access on both the resource and the resource’s container. To delete a resource, you must have Write access on both the resource and the resource’s container. See also CRUD Operations and Access Modes.
Append	Permission to add content to a resource: If a resource is a container (analogous to a folder in a file system), the Append permission on the resource allows agents to add new resources (container, RDF resource, non-RDF resource) to the container. If a resource is an RDF resource, the Append permission on a resource allow agents to add statements to the resource. See also CRUD Operations and Access Modes.

allow, deny Expressions

A policy statement specifies its access modes in allow(Access Modes) or deny(Access Modes) expressions:

• The allow expression specifies the access modes to be granted.

• The deny expression specifies the access modes to be denied.

An agent is granted an access mode for a resource if:

• The agent satisfies a policy that allows the access mode for the resource, and

• The agent does not satisfy any policy that denies that access mode for the resource.

For example:

• If a resource only has a single policy that allows Read and Write for an agent, the the agent is granted Read and Write for the resource.

• If a resource has:

  • A policy that allows Read and Write for an agent, and

  • A policy that denies Write for the same agent,

  Then, the agent is granted Read access for the resource.

If no “allow access” policy is satisfied for a resource, then that resource is inaccessible to the agent. That is, an unsatisfied “deny access” policy does not confer access. For example,

• If a resource has defined only a single policy that denies Read and the policy is unsatisfied by an agent, that agent still does not have any access to that resource.

CRUD Operations and Access Modes

This section summarizes the relationship between Create/Read/Update/Delete (CRUD) operations and the access modes.

CreateReadUpdateDelete

To create a resource, the user requires either an Append or Write access.

Note

The creation operation creates the resource (be it container, RDF resource, non-RDF resource) and updates the content of the parent container with the new resource’s metadata.

Resource	Description
Container	Either Append or Write access on the parent container (under which the new container is to be created) allows agents to create a new container. For example, to create https://storage..../parentcontainer/newContainer/, either an Append or a Write access on https://storage..../parentcontainer/ allows agents to create https://storage..../parentcontainer/newContainer/.
RDF resource	Either Append or Write access on the parent container (under which the new resource is to be created) allows agents to create a RDF resource. For example, to create https://storage..../parentcontainer/newResource/, either an Append or a Write access on https://storage..../parentcontainer/ allows agents to create https://storage..../parentcontainer/newResource.
Non-RDF resource	Either Append or Write access on the parent container (under which the new resource is to be created) allows agents to create a new non-RDF resource. For example, to create https://storage..../parentcontainer/foo.jpg, an Append or Write access on https://storage..../parentcontainer/ allows agents to create https://storage..../parentcontainer/foo.jpg.

Access Control Resource

Each Pod resource has an associated Access Control Resource (ACR) that contains the policies that determine access to the Pod resource.

The lifecycle of the ACR is bound to the lifecycle of the Pod resource; that is:

• When creating a resource, ESS creates a corresponding ACR.

• When deleting a resource, ESS deletes the corresponding ACR.

ESS’ Authorization Service hosts the ACRs.

If a resource has no Policies that apply to it, the resource is inaccessible. However, the Pod owner can add new policies to provide access to the resource.

Note

• Having read/write/append access to policies for a resource (i.e., write to the resource’s ACR) is distinct from having access to read/write/append the resource itself.

• See also INRUPT_AUTHORIZATION_CLIENT_ID_ALLOW_LIST.

Default Member Policies

If a resource is a Container, you can also specify Default Member Policies in the Container’s ACR. A Container’s Default Member Policies are used to initialize the ACRs of the Container’s children/descendents when they are created. As such, updates to a Container’s Default Member Policies do not affect existing children/descendents.

[1]

• Inrupt does not provide support for ESS servers running Web Access Control (WAC) in Production.

• The Access Control Policy (ACP) is in Draft status. Features based on draft specifications are subject to change.

Initial ACP Policies

When a Pod is created, an ACR is also created for the Pod Root, like any other Pod resource. The ACR is initialized with default ACP policies; the default policies depend on whether INRUPT_AUTHORIZATION_CLIENT_ID_ALLOW_LIST is set or unset:

Allow List is SetAllow List is Not Set

If INRUPT_AUTHORIZATION_CLIENT_ID_ALLOW_LIST is set (when creating the policy),

Policy 1 for the Pod Root:

If the agent matches the Pod owner’s WebID, and the client application matches a Solid-OIDC Client ID listed (when creating the policy) in INRUPT_AUTHORIZATION_CLIENT_ID_ALLOW_LIST , allow Read and Write.

Policy 2 for the Pod Root’s Default Member Policies:

If the agent matches the Pod owner’s WebID and the client application matches a Solid-OIDC Client ID listed (when creating the policy) in INRUPT_AUTHORIZATION_CLIENT_ID_ALLOW_LIST, allow Read and Write access.

For more information on default member policies, see Default Member Policies.

Note

INRUPT_AUTHORIZATION_CLIENT_ID_ALLOW_LIST only affects new ACRs. As such, any change to the list after the ACR has been initialized has no effect on existing policies.