Specification: Should it be possible to find controller of storage via resources?

[megoth]

(I think I've created an issue before that's close to this one, but I'm unable to find it right now - sorry if this is a duplicate, but think it's important to bump the issue for the specification editors to discuss.)

In the current data browser we have a function that gets the profile that is "the owner" of the Pod, i.e. the profile that is located in (Pod)/profile/card#me. This is hardcoded against the current implementation of Node Solid Server, and will break if NSS changes or on any other Solid Server implementation that don't follow this pattern.

Currently there is no way of detecting the "owner" (in lack of a better word) of a Pod from a given resource. (Or possibly "owners", if multiple WebIDs can be said to be owners of the given Pod.) I think this can be useful, as it allows us to give more context to the current Pod that someone is visiting, at least when visitig the "root of the Pod" (another term I know might be problematic, hence the air quotes).

It might be problematic for people to expose their ownership of a Pod, so if it should be part of the standard, we might want to make it opt-in. (The Pod Provider would still have access to the info, but accessing the WebID through resources, or just the root, might be hidden for everyone else by default.)

[elf-pavlik]

I think this can be useful, as it allows us to give more context to the current Pod that someone is visiting, at least when visitig the "root of the Pod" (another term I know might be problematic, hence the air quotes).

I recall conversation about root of the storage in https://github.com/solid/data-interoperability-panel/issues/10

Following terminology from auth draft resource controller(s) of the "root" in a solid storage would very likely set very restrictive ACL on that "level". If someone arrives to that "storage root" IRI for example following space:storage predicate in someone else's WebID Profile, they would most likely get HTTP 403 due to mentioned restrictive ACL on that resource/container.
For users who do have at least read access to the storage root, I think one could add statement to that container using space:storage predicate the same way as we use it in WebID Profile.

[RubenVerborgh]

The bigger blocker for this is that, strictly speaking, we don't model the concept of a "pod" in the Solid tech stack. E.g., you won't find predicates like "hasPod".
It's the same on the Web, really. On the Web layer, there are only linked documents. The notion of "server" disappears in the layers below.

So we would first have to explicitly model the pod, as part of another system that is independent of the current document-based infrastructure. This modeling of accounts etc. is the topic of another discussion somewhere.

[megoth]

@elf-pavlik Yes, that was the issue I was thinking about (in the Solid Data Interoperability Panel), thank you 😸

I understand that this is a complex issue, and might end up with us not being able to do what we currently do in the data browser. We'll support whatever decision the editors conclude.

If you can advice us to what we should do with the aforementioned function at some point in not to distant future (e.g. should we remove it altogether?), that would be appreciated.

[csarven]

Background on determining root(URI): https://github.com/solid/data-interoperability-panel/issues/10#issuecomment-598694029

Loosely speaking, if we agree on "determining" instead of "discovery", then an intuitive way to discover the "owners" (or controllers) of the root resource would be a simple relation eg. foaf:maker. What's around the corner is a way of discovering agents with particular roles involved with a resource eg. owner (the authoritative agent), administrator (to ask for stuff and nonsense). There are existing vocabs and ontologies around this.. and we can take a closer look at those. It could even end up as a simple shape in that every root resource should for example advertise a contact.

[elf-pavlik]

The bigger blocker for this is that, strictly speaking, we don't model the concept of a "pod" in the Solid tech stack. E.g., you won't find predicates like "hasPod".

I've commented in https://github.com/solid/data-interoperability-panel/issues/10#issuecomment-538122650 , https://github.com/solid/specification/issues/16#issuecomment-513830964 and various other places that while pod gets used more as vague buzzword, we seem to have pretty well defined term solid storage, and predicate space:storage where space:storage rdfs:range space:Storage.

@megoth in this issue and the other one about root url, when you use term Pod do you mean something distinct from Solid Storage discoverable from WebID Profile through space:storage predicate?

[megoth]

@megoth in this issue and the other one about root url, when you use term Pod do you mean something distinct from Solid Storage discoverable from WebID Profile through space:storage predicate?

No, I'm referring to storage. Sorry for the confusion.

[megoth]

I've updated the title of the issue to refer to storage, hope that's ok.

[RubenVerborgh]

^ Depends on: create a definition of "owner".
(At the moment, storage could have zero, one, or more owners.)

[elf-pavlik]

https://github.com/solid/solid-spec/blob/master/solid-webid-profiles.md#storage-discovery

Storage Discovery

A Solid WebID Profile SHOULD contain a link to one or more Solid Containers
that act as Storage (a space for apps to read and write data).

Example link to Root Storage (gets created
by default on account creation):

# ...
<#me>
    a foaf:Person ;
    <http://www.w3.org/ns/pim/space#storage> <../> .

---

Since Solid already establishes this predicate to relate WebID with Storage, I think we should see first if we could rely on this relationship for discussed scenario. If we take example where WebID Profile and Storage have more separation, we could have two independent documents including the same statement:

# https://alice.example/
<https://alice.example/#me>
    a foaf:Person ;
    <http://www.w3.org/ns/pim/space#storage> <https://alice.solidstorage.example/> .

# https://alice.solidstorage.example/
<https://alice.example/#me>
    <http://www.w3.org/ns/pim/space#storage> <https://alice.solidstorage.example/> .

If we find reasons to introduce another predicate than space:storage, I think we should clearly document how their meaning differs and how differently we intend them to be used.

[kjetilk]

Indeed, I think we need to have some explorations around "owner", as there are a few things that are centered around that agent, for example concerning recovery from Loss of Control (#67). As @RubenVerborgh says, it is tricky, because we need to change things conceptually. I haven't had time to think very carefully about that topic, so I follow your thoughts around using space:storage with interest.

Also note that we do have this explicit hierarchy in Solid pods, which could extend up to the authority (in RFC3986 sense), which could also possibly help in defining this.

[csarven]

The notion of server-managed or protected resources are covered in https://github.com/solid/specification/issues/65 as part of "auxiliary resources" in https://github.com/solid/specification/pull/156 . It is read-only for a client. It is intended to have information about the creator of a resource (among other claims).

A strict notion of "owner" of a storage is not necessary at this time - but we can revisit that if we need to. It can be pulled in the direction of the authority of the URI space, the controller of the resource, or the creator of the resource.

For the time being, the closest concept is the agent with control access on the root container. Pods or storage are typically instantiated with an agent having Control on the root container (ie. root path as per hierarchical containment). AFAICT, storage only becomes useful if there is an agent with Control on the root. Everything stems from that.

It can follow that: there should be a claim about the agent(s) that have control access as the owner/authority of the pod that's discoverable and readable from the server-managed resource. Servers should create this information when the first account (with WebID) is created. Server updates the server-managed resource as owner/authority/controller changes.

Client discovery and use:

1. Discovery of the server-managed resource (follow solid:managed)
2. Finding the description about the "controller" of the storage (eg. look for </> solid:controller <WebID>)

1 is nearly resolved. 2 the shape/description needs to be worked out.

Edit: using "controller".

[dmitrizagidulin]

I'd like to propose that we replace the term 'owner' with the term 'controller' (as in, resource controller or pod controller) -- see https://github.com/solid/authentication-panel/blob/master/oidc-authentication.md#resource-controller for example.

This would match the acl:Control terminology in WAC, the equivalent terminology in other peer specs, and side-step the legal issues in the concept of owner.

[csarven]

Yes, I think we have some consensus on preferring "controller" over the other terms.

This is not to say that "owner" (or perhaps along the lines of "authority" like for URI owner) can't be introduced. It is just that it is not grounded on anything right now that it can work alongside. Pragmatically, the closest is the agent with acl:Control on the root container.

[megoth]

@dmitrizagidulin I've updated the title to reflect your suggestion.

[csarven]

A proposal to determine the controller of a "pod" from a given resource:

The notion of a "pod" can be closely (if not exactly) matched with a resource of type pim:Workspace or possibly pim:Storage. To simplify, I'll refer to these notions as "Storage" here on. [The current draft spec defines "data pod" but we may need to revisit that.]

Process:

1. Have a self-describing resource claiming that it is a Storage.
2. Have a way to discover the Storage resource.
3. Have a way to discover the controller of Storage resource.

1 ) In practical terms, a Storage resource can be deemed to be a container (ldp:Container) in a URI space. Any of the following can be the Storage resource, whether stated in HTTP header (eg. Link: <http://www.w3.org/ns/pim/space#Storage>; rel="type") or in payload (eg. <> a <http://www.w3.org/ns/pim/space#Storage>), provided that an agent is authorized to obtain the information:

• http://example.org/
• http://example.org/foo/
• http://foo.example.org/

Aside: "root" can be framed in terms of URI authority as per RFC 3986, but that would exclude the possibility or make it difficult to express eg. http://eaxmple.org/foo/ as the Storage or "pod". I initially had some preference to using root path hierarchy to determine that: https://github.com/solid/data-interoperability-panel/issues/10#issuecomment-598694029 , but we can perhaps keep things open for now?

2 ) Given a URI, the algorithm MUST traverse up in the containment hierarchy (using shared slash semantics), examine the resource to see if it claims to be a Storage. As a wild guess, the algorithm MAY check the root path of a URI for the Storage claim.

3 ) The controller of the Storage resource can be determined by finding a claim along the lines of <storageURI> solid:controller <WebID>.

Aside: There is an ongoing discussion on discovery and data model about the controller/creator/issuer/maker of a resource managed by the server eg. the Storage resource may have a link relation with prov:has_provenance with target resource including provenance information that's managed by the server.

We can get through the finer details relatively quickly eg. which vocabulary term to use for "controller" or whether it is self-described in the Storage resource or found in an auxiliary resource using qualified patterns. I suggest to first have rough consensus on the notions and the process outlined above (or something like it) to move this issue forward.

[megoth]

Finding a container that identifies as Storage (or whatever term is best) via traversing the containment hierarchy sounds like a viable way. 👍 from me.

Sidenote: I think this is also useful for breadcrumbs that allow the user to navigate through their Pod, which would be a good addition to the Folder View in the Data Browser.