[wbs] response to 'Call for Review: Solid Working Group Charter'

The following answers have been successfully submitted to 'Call for Review:
Solid Working Group Charter' (Advisory Committee) for Mozilla Foundation by
Tantek Çelik.


The reviewer's organization opposes this Charter and requests that this
group not be created [Formal Objection].

Additional comments about the proposal:
   There are many problems with the proposed charter which merit Formal
Objections.

At a high level, the ”Motivation and Background” section states as a
reason: “give priority to individual and community autonomy, allowing
them to keep authority over their identity, data, and privacy, and giving
them the freedom to select applications and services that suit their
needs.”

This has been described in shorthand as the motivation for “personal data
storage”

This motivation sounds a lot like the motivations for:
* WebDAV, CardDAV, CalDAV — specifications which are interoperably
implemented across competing service providers and clients, that users can
choose, switch, and migrate between. Yet the Solid Charter says nothing
about what it is doing differently or even mention this prior work.

In addition, the W3C Social Web Working Group (2013-2018
https://www.w3.org/wiki/SocialWG) published a series of Recommendations
which now flourishing ecosystems supporting such personal data storage:
* ActivityPub + ActivityStreams2
* MicroPub + microformats2

And again, no mention is made of this prior art, the relation to the work
proposed in this working group, nor what the work proposed is doing beyond
that.

Thus the following specific problems are outlined:

* Technology-specific naming. WGs (especially brand new) should be the
named around a problem space (e.g. “personal data store”) not one
specific technological approach.

* Technology-specific scope. As I (Tantek) gave feedback both privately and
openly at the May AC meeting (looking for a minutes citation), W3C should
charter (especially brand new) WGs to solve problem areas rather than push
specific solutions. It is undesirable to charter a new WG that is focused
on a specific technical solution (SOLID) rather than solving the problem
areas e.g. “personal data store”. That said, this may be the wrong
granularity of problem space as well. See latter point about existing
Social Web WG RECs addressing parts of the problem space. Perhaps a
combination (since the two often overlap) “Social & Personal Web &
Data” would better describe this problem space and thus a WG to both
update existing W3C RECs in this larger problem area, as well as include in
scope additional approaches like SOLID that have been incubated and have
explicit multi-implementer interest/commitment/implementations seeking to
interoperate.

* The Solid Protocol has a copy-paste of parts of HTTP specifications, with
modifications.  Compare some of the normative statements in
https://solidproject.org/TR/protocol with those in
https://datatracker.ietf.org/doc/html/rfc9110. This is a bad practice
(monkeypatching more established technical work elsewhere) that is actively
discouraged by the IETF (see Section 2 of
https://datatracker.ietf.org/doc/html/rfc9205) and we’d like to see this
fixed before uplifting this kind of proposal from a CG to the scope of a
WG. If the intent is to use HTTP, then establishing the IETF HTTP working
group as a liaison is appropriate given this context.

* Personal Data Stores problem being addressed by existing W3C RECs adopted
by the market, which implies there is potentially a different (better)
problem space for a new WG (Social & Personal Web & Data):
_* ActivityPub + ActivityStreams2
_* MicroPub + microformats2

* Identity/authentication layer already has other adopted solutions: e.g.
IndieAuth (W3C Note), and no mention of FedCM CG which is also solving this
problem which makes it look like this WG (and those proposing it) are
unaware which is a bad sign.

* WG Charter appears to, by reference, setup a BDFL for all Solid related
specifications which is unacceptable. Here's how: Charter Deliverables
(https://www.w3.org/2023/09/proposed-solid-wg-charter.html#deliverables)
links to Solid Protocol, Version 0.10.0
(https://solidproject.org/TR/2022/protocol-20221231) has a Status of This
Document (https://solidproject.org/TR/2022/protocol-20221231#sotd) which
links to Solid process (https://github.com/solid/process) which says "The
following describes how changes to the specifications in the Solid
ecosystem may be proposed and accepted. Anyone may submit a proposal to
alter this process; such proposals will be approved only by Tim
Berners-Lee, who is the Solid Director."

* The one normative deliverable Solid Protocol (per
https://www.w3.org/2023/09/proposed-solid-wg-charter.html#normative) has
dependencies
(https://www.w3.org/2023/09/proposed-solid-wg-charter.html#dependencies) on
specs that are all currently only in a CG and are thus unlikely to make it
to CR or REC any time soon thus blocking progress beyond Working Draft
(WD). It is my understanding that normative references in W3C REC-track
documents MUST only refer to (normatively depend on) specifications at or
at most one maturity level below. E.g. a WD can depend on EDs, but a
Candidate Recommendation (CR) can only depend on WDs and above. Without a
concrete plan for reducing dependencies or advancing those dependencies
along a standards track, this appears to be a blocking issue for the one
normative deliverable.

* The Dependencies section
(https://www.w3.org/2023/09/proposed-solid-wg-charter.html#dependencies) is
misleading. That section says "Depending on the Working Group progress,
including consideration for adequate implementation experience, the Group
will also produce W3C Recommendations for the following documents". It is
misleading to only put these documents in a Dependencies section. The prose
"the Group will also produce W3C Recommendations" seems to imply these are
actually all additional normative deliverables within scope of the Charter,
yet they are explicitly listed outside of the Normative Specifications
section.

* We have questions about how the Team selected WG chairs without apparent
consideration of the existing CG chair. This looks improper and worth
objecting to until an explanation is made clear.

* Is Solid WG really a thinly veiled Inrupt WG? We would like to see
explicit disclosures on the existence of any financial relationships
between Inrupt and any consulting companies that are supporters or
contributing staff to this effort.


Answers to this questionnaire can be set and changed at
https://www.w3.org/2002/09/wbs/33280/solid-wg-2023/ until 2023-10-06.

 Regards,

 The Automatic WBS Mailer

Received on Saturday, 7 October 2023 04:00:04 UTC