This PR is intended to add the notion of "storage" that is commonly understood and in use. It includes other minor editorial for clarity.
Below is a non-exhaustive list of information pertaining to "storage" that I've taken into account for your reference/consideration.
<http://www.w3.org/ns/pim/space#storage> <http://www.w3.org/2000/01/rdf-schema#comment> "The storage in which this workspace is, or the storage which\ncontains this resource, or a storage available to this agent to use." .
<http://www.w3.org/ns/pim/space#Storage> <http://www.w3.org/2000/01/rdf-schema#comment> "A storage is a space of URIs in which you have access to data.\n"
<http://www.w3.org/ns/auth/acl#Authorization> <http://www.w3.org/2000/01/rdf-schema#comment> "An element of access control,\n allowing agent to agents access of some kind to resources or classes of resources" .
<http://www.w3.org/ns/auth/acl#owner> <http://www.w3.org/2000/01/rdf-schema#comment> "The person or other agent which owns this.\n For example, the owner of a file in a filesystem.\n There is a sense of right to control. Typically defaults to the agent who craeted\n something but can be changed." .
<http://www.w3.org/ns/auth/acl#delegates> <http://www.w3.org/2000/01/rdf-schema#comment> "Delegates a person or another agent to act on behalf of the agent.\n For example, Alice delegates Bob to act on behalf of Alice for ACL purposes." .
There is an architecture in which a few existing or Web protocols are gathered together with some glue to make a world wide system in which applications (desktop or Web Application) can work on top of a layer of commodity read-write storage. Crucial design issues are that principals (users) and groups are identifies by URIs, and so are global in scope, and that elements of storage are access controlled using those global identifiers. The result is that storage becomes a commodity, independent of the application running on it.
This can be called "socially-aware" storage, because the access control within the storage layer is just powerful enough to implement the social requirements of the social network applications.
Servers MUST provide one or more storages (pim:Storage) – a space of URIs in which data can be accessed. A storage is the root container for all of its contained resources (see Resource Containment).
owner
An owner is a person or a social entity that is considered to have the rights and responsibilities of a data storage. An owner is identified by a URI, and implicitly has control over all data in a storage. An owner is first set at storage provisioning time and can be changed.
we should be careful to name stuff that infringes on the authority of a storage (being roughly the same as a "pod", but I use the term storage, since that is what is specified) to control its URI space. This seems to turn into two distinct classes of things though: Those things that are within the URI space controlled by a storage and those that aren't. Those things that are within the space controlled by a storage should be discovered by interrogating the storage, but that leaves us with the requirement that storages must be really easy to discover, which they aren't now (#310). There should be a list of storages hosted by a server somewhere.
Solid is a specification that lets people store their data securely in decentralized data stores called Pods. Pods are like secure personal web servers for data. When data is stored in someone's Pod, they control which people and applications can access it.
This PR is intended to add the notion of "storage" that is commonly understood and in use. It includes other minor editorial for clarity.
Below is a non-exhaustive list of information pertaining to "storage" that I've taken into account for your reference/consideration.
https://www.w3.org/DesignIssues/CloudStorage
https://solidproject.org/TR/2021/protocol-20211217#data-pod
https://solidproject.org/TR/2021/protocol-20211217#storage
https://solidproject.org/ED/protocol#solid-app
https://solidproject.org/ED/protocol#owner
https://solid.github.io/solid-oidc/
https://solid.github.io/solid-oidc/primer/#solid-storage
https://www.w3.org/wiki/WebAccessControl
https://solid.github.io/authorization-panel/acp-specification/
https://solid.github.io/data-interoperability-panel/specification/#dr
https://github.com/solid/specification/issues/355#issuecomment-979503292
https://www.rfc-editor.org/rfc/rfc7231#section-4.3.4
https://www.rfc-editor.org/rfc/rfc7231#section-4.3.5
https://www.rfc-editor.org/rfc/rfc7231#section-9.1
https://solidproject.org/
https://solid.github.io/authorization-panel/authorization-ucr/#uc-inheritance
https://github.com/solid/authentication-panel/blob/main/proposals/HttpSignature.md
https://solid.github.io/notifications/protocol#notification-channel-discovery
Preview | Diff