Fundamental: why a Solid Profile spec?

[woutermont]

In this issue, I would like us to seriously reconsider the fundamental raisons d'être of the document being drafted here.

While it describes itself as a specification, the most voiced foundation seems to be to describe and preserve the way a limited subset of people currently use a number of other drafts within the Solid ecosystem. I do not have anything against current practices informing certain drafts, but I do think that specifications should start in a more specific need, and should be drafted based on arguments (e.g. use cases and technical considerations) rather than conservatism.

One concrete problem with the above genealogy, is that the document tries to do to many things at once. This causes it to be neither unique in its separate purposes, nor succesful in doing any of them very well. Especially, it results in each of these purposes being more tightly bound to others than necessary, which violates the principle of orthogonality, and thus complicates expandibility and compatibility. Therefore, I would like to propose us to split this document according to those specific needs that are found within the practices described, in order to tackle them separately, informed by current practices but based on sturdy arguments, and in cooperation with other drafts tackling the same problems.

Note that this is not only an issue of the WebID-Profile spec, but also of SAI, for example. Both contain too many pieces that overlap and could be merged into several smaller specs. Lots of powerful mechanisms on the Web work because of very small specs being able to work together.

---

A possible separation of concerns could look as follows.

1. A primary document should focus on authorization and application registrations, as suggested in Authorization & Application Registrations #62. The goal there should be to provide apps with a simple step from the identity of a user to a separate (sub)sphere where information can be found pertaining to the user's relation to that specific app. In other words: the application registration becomes the Profile extended with what that specific app needs and is allowed to.

2. Following the definitely justified separation of type indexes, and the issues raised in A social profile is not a discovery mechanism #65, a central discussion is remains how agents can discover where to access data. It remains important to note, however, that SAI is also looking into it, and most of both drafts are almost identical. Pooling the insights of both would prove much more valuable. Building this pooled insight on top of [1] is a must i.m.o.

3. We should remove the sections concerning the discovery of identity providers, storages and inboxes, as suggested in Keep the spec orthogonal, (oidcIssuer, indexes, inbox, storage) #63. If still necessary, e.g. as minimal interoperability bundle, we could form a (mini)spec addressing this.

4. If still wanted after Do not redefine "WebID" or "WebID Profile Document", clearly define "profile" #61 and Why does Solid need a specific social media style Profile spec? #64, this repo/document could continue to work on a way to provide some social media extension of the WebID Document, taking into account [1] and [2].

5. Apart from the normative documents in [1]-[4], a separate non-normative document could continue to describe current practice for a purely informative purpose.

EDIT: added [5].

[VirginiaBalseiro]

This feels like somehow a duplicate of #63 and maybe also #64. Can I ask you to combine them in one of the issues and close the others? Or I might have misunderstood the content of them, in which case, would you mind revising the title and have it be a clear summary of what your requested change/action is?

[woutermont]

Hm, let's see:

• Authorization & Application Registrations #62 argues that this document has permissioning problems;
• Keep the spec orthogonal, (oidcIssuer, indexes, inbox, storage) #63 argues to leave out the sections that only refer to other specs;
• Why does Solid need a specific social media style Profile spec? #64 argues that a specific social media style profile should be using Solid, not be a part of it;
• A social profile is not a discovery mechanism #65 argues that a social media style profile should not be used for discovery;
• About descriptive and normative documents #68 argues that this document cannot be discriptive and normative;

The current issue proposes to split up the doc according to those 5 topics, and on each join forces with the respective work in SAI and TypeIndexes. The reason I also opened separate issues is [A] to be able to discuss those points in more detail, and [B] because they still hold even if the document is not split.

Do you still think some should be closed without resolution?