Requirements for WebID document server

[RubenVerborgh]

No description provided.

[matthieubosquet]

I think the problem here is that the Solid Protocol says too much about WebID. It makes sense to me that a reference is made to it, but the middle statement should probably go:

When a WebID is dereferenced, server provides a representation of the WebID Profile in an RDF document [RDF11-CONCEPTS] which uniquely describes an agent denoted by a WebID.

Without that statement above, the spec could link to the relevant documents, respecting the spec orthogonality principle as such:

A WebID is an HTTP URI denoting an agent, for example a person, organisation, or software [WEBID].

WebIDs are an underpinning component in the Solid ecosystem and are used as the primary identifier for users and applications [SOLID-OIDC] [WEBID-TLS].

[csarven]

The Solid Protocol does not describe the requirements for the HTTP server hosting a WebID document.

[1] The Solid Protocol does describe a WebID document served from a Solid server, i.e., to have representations of a WebID Profile Document available in Turtle and JSON-LD, and as per content negotiation it may be available in other media types (typically in concrete RDF syntaxes).

Other Solid specifications seem to also (implicitly) make assumptions, notably:
Servers are strongly discouraged from trusting the information returned by looking up an agent’s WebID for access control purposes.

Not relevant because WAC does not have a requirement to dereference a WebID or have the WebID Profile Document available in any particular format. WebID is only used as an identifier for agents.

I think the problem here is that the Solid Protocol says too much about WebID. It makes sense to me that a reference is made to it, but the middle statement should probably go:

The statement is in context of the Solid Protocol [1] - it may be redundant and can be removed on that basis.

---

The WebID section can be updated to be more clear about any "HTTP server hosting a WebID document" as opposed to strictly Solid servers as per the Solid Protocol. This is essentially factoring in the requirements put forward by the other core specifications. The current text using "RDF document" in the normative section generally covers that possibility:

When a WebID is dereferenced, server provides a representation of the WebID Profile in an RDF document [RDF11-CONCEPTS] which uniquely describes an agent denoted by a WebID.

It leaves it up to each specification in the ecosystem to make their own specific and definitive calls.

If instead all of the Solid specifications want to use one-requirement-to-rule-all-requirements on WebID in the whole ecosystem as per Solid Protocol, we can also do that - provided that the groups working on each specification are aligned with that. (As it stands, that practically means acknowledging both Turtle and JSON-LD.)

[csarven]

As per WebID 1.0 ED, a WebID document is an RDF document. Representation in Turtle being the minimum requirement for interop whilst standard content negotiation takes place.

The Solid Protocol specifies Solid server requirements for serving RDF documents: https://solidproject.org/TR/2021/protocol-20211217#server-representation-turtle-jsonld . A conforming Solid server will provide WebID documents in Turtle and JSON-LD.

Currently, the Solid Protocol is not describing how any HTTP server (under the sun) should serve a WebID document (besides it being an RDF document and adhering to WebID 1.0 ED). The Solid Protocol does not - or in a position to - dictate how WebID documents are to be served from HTTP servers besides the Solid server or potentially the servers that can participate in the Solid ecosystem.

As said earlier, in order to use the Solid Protocol as a reference point for all specifications in the Solid ecosystem, there needs to be agreement across the current (and upcoming) specifications on a requirement that they can all rely on. In its absence, the current WebID section in the Solid Protocol merely states that those documents are deemed to be RDF documents. Hence, a server hosting a WebID document in the Solid ecosystem is a Solid server, in which the requirements are given by the Solid Protocol (Turtle, JSON-LD) or a server (as defined by a particular specification in the Solid ecosystem) that conforms to WebID 1.0 ED (Turtle). As it stands, any other kind of "server" would either be not conforming to WebID 1.0 ED or Solid Protocol or extends either one of those.

[timbl]

This is NOT clear IMHO because we have a WebID 1.0 Editors Draft spec which specifies what the server of a WebID must support, and the SolidOIDC people use the term "WebID" without distancing themselves from the WebID spec, and not supporting it.

[csarven]

Specifications defining roles that serve a WebID Profile Document that do not conform to the Solid server should specify the ways that the consumer of the WebID Profile Document can discover the resource which accepts read-write operations as per the Solid protocol. For example, the Solid WebID Profile specification can describe the property that enables the discovery of a WebID Profile Document on a Solid server, e.g., solid:profileDocument, unless the discovery of a WebID on a Solid server is intended, e.g., solid:webid. The other specs, e.g., Solid-OIDC can recommend its use.

[timbl]

You are saying that SolidOIDC ID document must contain something like
<#me> solid:profileDocument <https://example.com/aliice/card> .
then ?
or maybe
<#me> solid:ID. <https://example.com/aliice/card#me> . .... ?

[elf-pavlik]

AFAIK all comments about solid:profileDocument are about
Solid WebID Profile: https://solid.github.io/webid-profile/
NOT about Solid-OIDC: https://solidproject.org/TR/oidc#webid-profile

[csarven]

Tim, with respect to this issue, I'm saying that any specification that requires or anticipates dereferencing WebIDs - which may resolve to a non-Solid server - can consider recommending the discovery of that person's other or preferred WebID that is hosted on a Solid server.

My inquiry about solid:profileDocument or solid:webid was about what's intended to be discovered. I think solid:webid makes more sense as that actually seems to be what's intended - enables any WebID (on the face of the planet) to link to a Solid WebID where a Solid-aware application can perform read-write operations. I've created solid/webid-profile#58 to specifically discuss that concept.

I recommend closing this issue with the understanding that Solid Protocol is clear about the requirements. If other specs have different requirements, and want to make it possible for applications to find their way to WebID that in conforms to the Solid Protocol, there needs to be a discovery mechanism - a property perhaps.

[csarven]

Changed the status to Waiting for Commenter again and asking @RubenVerborgh whether the answers are satisfactory and asking if @timbl is satisfied or has objections to close this particular issue.

[csarven]

I feel we are now awfully close to repeating ourselves. For example, the last paragraph in #376 (comment) as to what the current expectations are and whether people want something stricter, e.g., make sure all Solid specs work with or set the same requirements for WebID representations.

(Side-note: this paragraph has chosen not to use MUST language.)
I only see the rather ambiguous "When a WebID is dereferenced, server [sic] provides a representation of the WebID Profile in an RDF document", but there is no specific mention of this being a Solid server.

So? It is a normative section. It is describing something about the ecosystem where the Solid Protocol plays one of the key roles. The Solid Protocol is only describing something that is already compatible with the current WebID 1.0 ED.

I just don't see it in the spec; I don't see a line saying "WebIDs MUST be served from a Solid server".

I.e., if these above lines are sufficient, could someone please ELI5 me step by step how I know that the WebID MUST be on a Solid server; and if that is too much of an inference to make, can't we just add it explicitly?

Different things are referencing WebIDs and different things are dereferencing WebIDs.

A Solid application needing to read the WebID Profile Document (from somewhere on the Web) only needs to follow (current) WebID 1.0 ED's requirement, i.e., Turtle or another concrete RDF syntax depending on negotiation. A Solid application will need to be equipped to work with Turtle or JSON-LD so that it can communicate with a Solid server. If a subset of the WebIDs that the application wants somewhere on the Web is on a Solid server, all is still well.

I'd argue - anecdotal evidence - that we've been building applications with that understanding, i.e., Solid applications do read WebIDs that are not hosted on Solid servers. (For example, and as you know, dokieli will go through all of my and my contact's connected WebID when it needs to. The use case is to read. It doesn't have a need to write to every WebID based on Solid) There is a lot of value to be able to use WebIDs that are not strictly on a Solid server. There'll be more applications needing to read than to write WebID Profile Documents.

Having said that, I'd still argue that we need to strive for a mutual understanding that when a WebID is not a Solid server, then obviously a Solid application won't be able to perform (access controlled) write requests to it. And, for those subset of WebID owners (one having sufficient rights to update the WebID Profile Document by any means - see e.g., webid-profile issue 58) wanting to lead Solid applications to follow their nose to their equivalent or alternate WebIDs that are on a Solid server, then we specify that bridge.

Hope that helps as to at least how I'm looking at this.

[langsamu]

Somewhat related implementation feedback, though not addressing the substantial question.

In the Inrupt Enterprise Solid Server 2.0 (which I contribute to) WebIDs are not stored on a Solid server. Instead they are stored on a separate service that adheres to WebID ED and Solid-OIDC.

This is to support multiple use cases and customer requirements regarding separation of identity from storage.
For example identity in the form of WebIDs might be provided by someone other then the storage provider.
Another example: Access control to the WebID profile might fundamentally differ from access control to Solid resources.

It would be impossible to support these use cases if the WebID of the Pod owner was required to be stored in the Pod they own.
And it would be too much effort for implementers if we just required WebID servers to be Solid servers.

[woutermont]

@RubenVerborgh, if something still bothers you about this, could you try to explain it once more? A few days ago I thought I was following, but I'm no longer sure of that.

I.m.o. the interrelations are quite clear: Solid specifies servers, WebID specifies identifiers and documents; Solid servers can host non-WebID resources, non-Solid servers can host valid WebID documents, and a WebID document on a Solid server adheres to both. Most importantly, for most of the very specific cases where WebIDs are used, one hosted outside of Solid works perfectly. Nothing in the spec seems to contradict that, even if some wording could be clearer.

I do agree with @matthieubosquet, however, that the Solid protocol (and other Solid specs) contains too much useless text about WebIDs. Most of it is repetition or paraphrasing of the WebID spec, which not only makes it redundant, but also increases the risk of confusion should the wording be not exactly the same. Some of it also creates too tight a coupling with WebID, where a simpler description (e.g. "dereferencable to RDF resource containing X") would suffice.

[TallTed]

[@woutermont] the Solid protocol (and other Solid specs) contains too much useless text about WebIDs. Most of it is repetition or paraphrasing of the WebID spec

There is good reason for this "useless" text being in the Solid docs. Simply put, the WebID "spec" remains a draft document, with zero guarantee of stability. "Repetition or paraphrasing" of that draft document's content wherever it is meant to be relied on remains the best way to ensure that Solid implementers can follow the Solid-intended text.

[woutermont]

Since those paraphrases can contain errors, and only make sense when combined with a reference anyway, the best way to ensure a robust foundation would actually be to refer to the WebID 1.0 Draft of 2014-03-05 directly instead of to the latest version of it.

[csarven]

the Solid protocol (and other Solid specs) contains too much useless text about WebIDs. Most of it is repetition or paraphrasing of the WebID spec

Since those paraphrases can contain errors,

Hopefully not as bad as hot interpretations of specs in issues.

You make it sound like as if there is an essay in place. The minimal text serves as an entry for a key component (Identification) part of the Solid Protocol. Again, "the Solid Protocol is only describing something that is already compatible with the current WebID 1.0 ED."

The section can be extended to connect concepts and behaviours involving WebID that are described elsewhere in the document as well as external documents.

the best way to ensure a robust foundation would actually be to refer to the WebID 1.0 Draft of 2014-03-05 directly instead of to the latest version of it.

https://www.w3.org/2005/Incubator/webid/spec/identity/ is adequate as a reference to the Editor's Draft and presumably equivalent to being the latest published version. Here is more context w3c/WebID#5 that you might find useful, and one of the things that's on WebID CG's table.

I'll be among the first to say that text can (and should) be improved, but I can assure you that there is a bit more thought put here than slapping some "useless text", in addition to TallTed's constructive view of the state of things.

[woutermont]

@csarven, I might have used some rhetorical hyperbole, the term 'useless' should probably have been more in the lines of 'redundant', and once more our keenness for abstraction seems to differ. The point remains: there is text that would not matter if left out, and if the instability of a draft is the issue, then the best way would be a referrence to its fixed version.

I do not see what about this is less constructive than @TallTed's contribution, and I feel in fact somewhat hurt in your karikature of me. Especially since my original comment just asked for confirmation that this issue could be closed again.

[csarven]

The point remains: there is text that would not matter if left out, and if the instability of a draft is the issue, then the best way would be a referrence to its fixed version.

It is completely okay if we have different views about this. The current text is first and foremost intended to be useful for the reader. If and when the target reference changes, we can review and update the Solid Protocol as accordingly. To be clear, I don't oppose linking to another (versioned) URL but note the state of things in the linked issue above, as well as the fact that webid/spec/identity/ URL has always been the primary reference in documentation, discussion, and code.

[melvincarvalho]

I feel in fact somewhat hurt in your karikature of me

@csarven please, be respectful. Try to phase feedback, without something that could be interpreted as a passive aggressive jab. Let's assume good faith, and that everyone is trying to be constructive. Thanks!

[bblfish]

Just my two cents.

• I am ok with clients being required to know JSon-LD and Turtle,
• my recent inspection of json-ld parsers for Java gave me a bad impression: I looked at Titanium and it is not async, need to open a new connection (probably on a java thread), etc... That does not look good to me. If I had time I would sit down and fix that, but it could take two months.
• Aaron's use case for json-ld he put forward here seems a reasonable one Required RDF serialization of WebID resource w3c/WebID#3

So my feeling is for exceptional cases like that it makes sense.

On the whole I am not overly enthusiastic though. I don't think Solid is suffering because it is not serving data in enough formats. There are a lot of higher priority things to do...