Keep the spec orthogonal, (oidcIssuer, indexes, inbox, storage)

[woutermont]

As I've already argued multiple times elsewhere in this repo and on the gitter channel, the document being drafted here wants to do too much: if everything in the current draft is one of the goals, the goal is to do everything at once. In this particular issue, I would like to point out this overreaching in sections 5, 6 and 7. They concern the discovery of, in order, the OIDC identity provider(s), the Solid storage(s), and the LDN inbox(es).

All three sections start by mandating or recommending a triple that is already part of some other discovery mechanism, and then continue either to trivially repeat what is made possible by the spec governing that mechanism, or to incautiously place restrictions upon the mechanism that should better be mandated by that respective spec itself. Most importantly of all, however, none of these sections is needed to make anything else in the WebID-Profile proposal work; the sections are not referred to, and their presence or absence does not influence what's described in any of the other sections. In other words: these are orthogonal concerns and, even if their content could somehow prove valuable, these sections should thus be separate specifications (as has, for example, also been suggested by @csarven about the inboxes).

In short: it is already possible to add links to one's OIDC issuer(s), Solid storage(s), or LDN inbox(es) in one's WebID Profile, and even if there is a function-specific need to further restrict those mechanisms in separate specifications, they are of no concern to WebID-Profile spec.

In light of this, my suggestions would thus be:

• to remove these sections from the WebID-Profile draft;
  • remove the OIDC section;
  • remove the Solid storage section;
  • remove the LDN inbox section;
• to refer specific issues to their respective specification (OIDC, LDN, Solid Protocol or some discovery spec like TypeIndexes or SAI);
• to consider whether some of their content should be worked out in a separate document (either existing or new); and
• to focus on use cases specific to social media style profiles (if that is what this spec wants to do).

EDIT: striked through misinterpretation of @csarven's words, even though the result is i.m.o. the same.

[jeff-zucker]

In regards to solid:oidcIssuer, we have agreed amongst ourselves that this is orthogonal to our spec.

In regards to type indexes, those will also be regarded as orthogonal to our spec and have been separated out into their own spec.

In regards to ldp:inbox and pim:storage, I agree we should point to LDN and other specs but I believe these have a special relationship to a Solid Profile and that we should cover some aspects of them. The recommendations in the current draft need re-writing, but I think we will have such sections, though perhaps non-normative ones.

[jeff-zucker]

In regard to use cases - yes, we are working on a use cases section now.

[woutermont]

In regard to use cases - yes, we are working on a use cases section now.

I particularly meant use cases pertaining to the social media style profile, assuming that not much else will be left for this document.

In regards to ldp:inbox and pim:storage, I agree we should point to LDN and other specs but I believe these have a special relationship to a Solid Profile and that we should cover some aspects of them.

Okay. Then I believe we should first document for each of them [A] which needs we have that require additional constraints on top of their origin spec, and [B] why such constraints should be specified in this document, rather than in another (new or existing) one.

[csarven]

these sections should thus be separate specifications (as has, for example, also been #56 by @csarven about the inboxes).

No. What I suggested in #56 (comment) was that the Solid WebID Profile spec need not emphasise on any particular access permissions on an inbox.

If Solid WebID Profile strips everything out as optional in order to be infinitely extensible or abstracted, the spec will not serve its purpose. Solid WebID Profile is social at its core, so a profile does need to include some fundamentals to be useful or interesting.

[woutermont]

these sections should thus be separate specifications (as has, for example, also been #56 by @csarven about the inboxes).

No. What I suggested in #56 (comment) was that the Solid WebID Profile spec need not emphasise on any particular access permissions on an inbox.

Well, apologies for the misinterpretation. But except for those particular access permissions, there's nothing in that section really, not counting the statement that you can indeed add an inbox to your WebID Document, which is what you get from WebID + LDN anyway.

If Solid WebID Profile strips everything out as optional in order to be infinitely extensible or abstracted, the spec will not serve its purpose. Solid WebID Profile is social at its core, so a profile does need to include some fundamentals to be useful or interesting.

Thanks @csarven, that is precisely my point: this spec has no purpose. OIDC, LDN, TypeIndexes, FOAF etc. enable us to use their mechanisms by adding certain triples to our WebID Profile. We don't need another spec to say: you could do all this separately, so now you can also do them all together.

The only thing that this spec seems to add is the stubborn idea that these triples and more data-about-the-WebID-referent MUST be in the (extended) profile, because "that is how we do things today."

[csarven]

There is more to achieving minimal interoperability between multiple implementations than merely saying there is an ocean of standards that they can use at random.

The purpose of this spec (as any other spec) is to explain how specific interoperability occurs.

[woutermont]

I understand the value of doing so; of bringing together a few much-used specs into a minimal whole; and I'm not questioning that. What I'm trying to point out is the following.

---

[A] Specs start out from a specific goal, and the things they specify are always in aim of that goal. WebID-Profile brings together loads of stuff without any real connection to its goal. As I have stated at the beginning of this issue:

[N]one of these sections is needed to make anything else in the WebID-Profile proposal work; the sections are not referred to, and their presence or absence does not influence what's described in any of the other sections.

It is thus not clear how having an inbox, and definitely a storage and OIDC issuer, in your WebID is in aim of the goals of the spec. Even more, it is not clear at all what the goal of the spec is meant to be. The only thing that comes close to it are some sentences in the README of this repo, stating:

The general purpose of this document is to describe what an app can discover based on the WebID. [...] This specification aims to describe the discovery process as it is currently in use.

As I've argued in #68, this is i.m.o. a contradictio in terminis. One can describe how things are (which this document does a great job for), OR one can specify how things should be; one CANNOT do these two things at once, because they are (often) not the same. If this document is expected to do the former, it should leave out normative terminology. If it wants to do the latter, it should take into account decent arguments about why some ideas are better than the current practices.

---

[B] Precisely because of incompatibility of norms and descriptions, the WebID-Profile document endangers the progression of Solid. If its aim is indeed "achieving minimal interoperability between multiple implementations," as you say, @csarven, it is doing a very poor job indeed. Making the descriptive normative, i.e. recommending to do exactly as things are, not only creates a standstill for implementations following this "spec", but also renders them uninteropperable with implementations that do not follow it. In concreto, implementations following SAI will not be able to use the same pods as those using WebID-Profile. Even more: implementations following TypeIndexes will not be able to work decently (-I could stop here-) with those storing data in the Extended Profile, even though both are recommended in this document. Arguments showing these points are littered through the repo's and gitter channels by @RubenVerborgh, @elf-pavlik, @acoburn, myself and possibly others.