Require pim:storage predicate if WebID is in agent's storage

[jeswr]

Following the discussion in solid/specification#772 - this PR requires that WebID's conforming to the Solid WebID profile use pim:storage to advertise the storage in which a WebID is contained, if the WebID is contained in Solid Storage.

The goal of this is to prevent the majority of client applications from needing to implement discovery of storages using link headers.

[Copilot]

Pull request overview

Updates the Solid WebID Profile specification to require advertising storage via pim:storage when a WebID is contained within Solid Storage, aiming to reduce the need for clients to discover storages via Link headers.

Changes:

• Strengthens the pim:storage guidance by adding a normative requirement to advertise the containing storage when applicable.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The new requirement sentence is ungrammatical (missing “is”) and currently ambiguous about what it means for a WebID to be “in an agent's storage” (WebID URI vs WebID profile document location). Please rephrase to clearly define the condition (e.g., when the WebID Profile Document is contained within a Solid Storage) and what exact storage URL must be advertised via pim:storage.

Suggested change

	<li>Zero or more <code>pim:storage</code> properties to indicate agent's storages. If the WebID in an agent's storage, that storage MUST be advertised.</li>
	<li>Zero or more <code>pim:storage</code> properties to indicate the agent's Solid storages. If the Solid WebID Profile Document is contained within a Solid Storage, the URL of that storage (for example, the root container URL of the storage) MUST be advertised via <code>pim:storage</code>.</li>

[jeff-zucker]

So, if the profile is located in a non-Solid server it's okay to not have a storage predicate? I think, the same conditions apply. Also I would change it to "If the WebID owner wishes to advertise their storage, they MUST ...". Because having a WebID without a public storage is a valid use case.

[VirginiaBalseiro]

Not all WebID holders have a storage. This requirement would create a tight coupling and a need for every WebID to have a storage and/or disclose it. Some users might not want to make that information available.

Storage Description already provides a mechanism for discovery. I understand that developers get this wrong in practice, but that is not sufficient grounds for a conformance requirement.

Off topic, I want to kindly request to turn off Copilot for this repository, of which I am an editor. I do not have sufficient access to do so.

[jeswr]

This requirement would create a tight coupling and a need for every WebID to have a storage and/or disclose it. Some users might not want to make that information available.

This change does not require that every WebID have a storage. With this change a WebID can still be stored outside a storage -- and if so, can still have zero pim:storage statements.

Some users might not want to make that information available.

The intent of the change is to only require that the pim:storage be included when that information is already available because the WebID is in a storage and thus the root is discoverable via the Storage Description. i.e. there is no intent to degrade user privacy with the change in this PR.

Off topic, I want to kindly request to turn off Copilot for this repository, of which I am an editor. I do not have sufficient access to do so.

Can do - I just need to find the right setting since there doesn't seem to be an "off" button in the repository-level settings.

Done!

[elf-pavlik]

The goal of this is to prevent the majority of client applications from needing to implement discovery of storages using link headers.

Could you please clarify what problem do you see with following existing discovery mechanism via Storage Description? LWS is leaning heavily in advertising services and capabilities in Storage Description https://w3c.github.io/lws-protocol/lws10-core/#discovery

[csarven]

Following the discussion in solid/specification#772 , and as mentioned a few times, some agents may not wish to advertise a storage.

Omitting it is legitimate for privacy (and selective disclosure), architectural reasons.

As mentioned in the introduction's use cases, there are different circumstances under which profiles are used or shared, including anonymous, pseudonymous, and meronymous profiles.

An agent might intentionally omit storage, and if an agent is truly the URI owner, this desire to omit should be respected. In fact, Solid Protocol's Privacy Considerations section mentions WebID Profile Privacy:

The decision to include or exclude any information (e.g., storage, inbox) in a WebID Profile served from a Solid storage lies with the Agent controlling the WebID (or the URI owner). A URI allocated to a WebID in a Solid storage does not imply that the WebID is the storage owner.

If a WebID Profile happens to be part of a storage, a client can infer the storage root by walking up the URI hierarchy, but only when WebID and storage are co-located ( https://solidproject.org/ED/protocol#client-storage-discovery ), which is not guaranteed.

Some profiles may legitimately serve as nothing more than an authentication anchor, without any association to a storage.

So, the current model suggesting that 0 or more is appropriate.

---

On a related note, some folks are arguing that a Solid WebID Profile ought not to be hosted on a server with Solid Protocol write capabilities, while others (possibly overlapping) are arguing that it must be hosted on one. 🤷

[elf-pavlik]

BTW why do we need both pim:storage and solid:owner ?
https://solidproject.org/TR/protocol#server-storage-link-owner

Putting aside MUST/SHOULD/MAY, can solid:owner simply be used from both directions?

[jeswr]

As discussed in todays CG call, the fact that "A URI allocated to a WebID in a Solid storage does not imply that the WebID is the storage owner." is sufficient reason for clients to not try and discover storages owned by a WebID from the storageDescription of the resource.

Hence the maintainer of a WebID and their extended profiles should ensure that pim:storages are appropriately added, and should not ensure that clients will discover user storage from storageDescription link headers.