Pod Resources
Resource Types
ESS Pods supports storing different types of resources:
CRUD Operations
ESS supports the Solid Protocol specification. As such, retrieving, creating, deleting and editing Solid Resources within a Pod is directly supported via the standard HTTP interfaces.
Access Control
This section summarizes the relationship between Create/Read/Update/Delete (CRUD) operations and the required access modes.
To create a resource, the user requires either an Append
or Write
access.
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/
.
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
.
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
.
Other Considerations
Resource Deletion
For resource deletions, ESS uses soft deletes. That is, ESS marks the resource as deleted but does not perform an actual delete from the data store. The use of soft deletes can:
Help maintain throughput when compared to database delete operations that may be potentially costly due to locking.
Facilitate disaster recovery.
Be part of a data-retention strategy.
ESS provides the ability to schedule hard deletes for the soft deleted resources
Modification of Resource Content
When data in a file is modified or deleted, the old data remains but is no longer referenced by metadata. That is, the replaced/deleted data is orphaned.
ESS provides the ability to schedule hard deletes for the orphan data.
Initial Access Policies
When a Pod is created, like any other Pod resource, an Access Control Resource is also created for the Pod Root. The ACR is initialized with the default ACP policies for the Pod Owner and for Access Grant enablement:
Initial Pod Owner policies give the Pod Owner read and write access to the Pod. These policies also specify a client matcher as well if the Authorization service’s configuration for the initial client allow list is set:
INRUPT_AUTHORIZATION_DEFAULT_ACR_CLIENT_ID_ALLOW_LIST
or if that is unset,
Using the value of the Pod owner’s WebID and an initial client allow list, ESS creates the initial policies of the form:
If allOf(AgentMatcher and ClientMatcher) evaluates to true, Then allow (Read and Write).
Specifically, ESS creates:
Policy 1 for the Pod Root: If the agent matches the Pod owner’s WebID, and if the client application’s Client ID has a match in the initial client allow list, allow Read and Write access.
Policy 2 for the Pod Root’s Initial Member Policies: If the agent matches the Pod owner’s WebID, and if the client application’s Client ID has a match in the initial client allow list, allow Read and Write access.
For more information on a Container’s Member Policies, see Member Policies.
Disambiguation
Both Authorization Service and Pod Storage Service have a INRUPT_AUTHORIZATION_CLIENT_ID_ALLOW_LIST
setting.
Only the Authorization Service setting affects which clients are allowed. The Pod Storage Service is for Discovery purposes only.
Initial Access Grant Enablement policies allow the use of Access Grants that grant read/write/append access to the Pod resources.
If allOf(VC Matcher) evaluates to true, Then allow (Read and Write and Append).
Specifically, ESS creates: Policy 3 for the Pod Root: If a presented VC matches the specified type, allow its use for Read, Write, and Append access. Policy 4 for the Pod Root’s Initial Member Policies: If a presented VC matches the specified type, allow its use for Read, Write, and Append access. See also
INRUPT_AUTHORIZATION_DEFAULT_ACR_ACCESS_GRANTS_ALLOWED_MODES
.
Important The policies only enable the use of Access Grants 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 policy, and
The granted access specified in the Access Grant (for the resource specified in the Access Grant).
Last updated