Structuring data in Solid

Digita and use.id can only guarantee data/access persistence over the transition to newer evolutions of the Solid specifications, if they are according to the following structures.

Structure of pods

Each client will have a specific container in each user’s pod, which will be created upon provisioning. The container’s name will be the SHA-256 hash of the client WebID.

Within this container, the client will have all the rights, and the user initially only read access. It is up to the client to give the user or other parties further access to data in their specific container. Be advised, however, that until transitioned to a newer version of the Solid specifications, any parties given write or control access can form a security risk.

Structure of data

All data must adhere to a Shape Tree, as defined by the ShapeTrees specification, which describes the expected layout of a tree of resources. The definitions of the Shape Trees can be hosted anywhere that is publicly accessible, but Digita will provide a space to do so in the pod attached to the client WebID. See our example on Shape Trees for how to construct these.

Any data written within the client-specific container of a user’s pod must be put into a flat hierarchy of subcontainers sorted per Shape Tree. The name of each of these subcontainers must be the name of the Shape Tree. When writing the first data adhering to a certain Shape Tree, i.e. when the corresponding subcontainer does not yet exist, it is up to the client to create that container.

Structure of access control

As stated above, it is up to the client to give the user or other parties access to data within their client-specific container. The client can do this by writing or changing the necessary access control resources (ACL files) corresponding to the subcontainers and resources it wants to grant access to. When doing so, the client must take the following rules into account.

• Access must always be granted to a complete instance of a Shape Tree, i.e. someone cannot have access to only part of the tree. For example, if a certain Shape Tree describes a kind of data consisting of three different resources, access must be given to all or to none of them at the same time.
• Whenever access to some data is granted/changed to some agent in the ACL files, the corresponding Access Needs, as defined in the Interoperability specification, must be made/updated within the subcontainer of the client-specific container, called .sai. See our page on Access Needs for how to construct these.