Re: next step for the Solid WG charter

Hi all,

I'm only following the discussion going on about the Solid WG Charter, but I'm getting a bit worried about the progress being made.

My interest is mainly how to engage with (Public Sector) organisations who believe Solid is a possible alternative for the current focus on a API first and Cloud Native strategy only, by including the context of the end-users (citizens) in a Solid Pod. It is really my believe that the Solid principles are the solution for that, but Solid is nothing without agreed upon (W3C) specifications, supported and implemented by both open source and closed source developers. Ultimately it is about proven (Pod) solutions which can co-exist en interoperate with other (existing or new) decentralised components like EDI-Wallets, Rules Engines, Access Management tooling and Data Access and Management tooling.

I agree with Pierre-Antoine that we need to separate Pods from Identity and Access Management, there are other WG's for that, but focussing only on LDP would not be sufficient.

Focus on semantics and standardisation is fundamental as we also see from the many initiatives in the Netherlands in Health, Energy, Real-Estate, Government, ... They all require transparant data acces (in way like Fraunhofer proposes with their Solid Data Space (see [paper](https://dl.acm.org/doi/fullHtml/10.1145/3543873.3587616) and [presentation](https://solid.iis.fraunhofer.de/SCS-DS-IoT/public/2023/solid%20symposium/potentials%20and%20limitations/20230331_SMeckler_SolidforDataspaces.pdf)) and need to be fully interoperable with governmental data, data from NGO's and personal data (I would like to see data here as component (or a product) like in data meshes). Linked data is the best option here (see [Dutch Cadastre example](https://www.geonovum.nl/geo-standaarden/imx-geo-semantisch-model-basis-en-kernregistraties)), but requires full data management (see [Oracle](https://www.ateam-oracle.com/post/using-oracle-database-as-a-solid-data-store)) to make data re-usable and data organisation (data containers) capabilities to make it manageable by the end-user.

In the end it is about being able make the different components (either Sold specific ones or existing ones) working in unison, scalable, fully interoperable, interchangable (independent of the implementation), secure, privacy respecting and user-friendly.

So componentisation is key and prioritisation is needed. I guess a Reference Architecture with these components and how they relate to which specification/standards might help showing the dependencies.

I would hate to see losing the grip on Solid, because we are not able to get ourselves organised. This is the only chance to create (Solid based) breakthrough technology, but alternative technologies are already on the horizon.

My 2 cents.

Beste regards,

Han Wammes
Public Sector Lead
Solid Community Foundation Netherlands
+31 6 2119 4540
[LinkedIn](https://linkedin.com/in/hwammes)

Verzonden met [Proton Mail](https://proton.me/) beveiligde e-mail.

Op vrijdag 17 november 2023 om 13:17 schreef Sylvain Le Bon <sylvain@startinblox.com>:

> Hello Pierre-Antoine,
>
> Thanks for this proposition, I find it really sensible. I feel like the fuzziness about the scope of Solid is a problem as it sometimes makes it hard to discuss. Your suggestion would make things very clear in that aspect.
>
> One thing, though, might be missing in your pitch and the expected outcome. I feel like the data access/content negotiation/client-to-client/shapetree part is very important in the picture and could be worth adding.. I leave it to your collective wisdom to decide whether that should be considered part of the scope or too early/different to be included.
>
> Thanks a lot!
>
> Le ven. 17 nov. 2023 à 11:31, Pierre-Antoine Champin <pierre-antoine@w3.org> a écrit :
>
>> Dear all,
>>
>> (this is a summary of a point I already presented during Wednesday's
>> call [1])
>>
>> we have received a long awaited review from the TAG (the W3C Technical
>> Architecture Group) on the Solid WG charter proposal [2]. This review
>> echos and synthesizes a number of comments already made by some of the
>> AC reviewers. It makes addressing those concerns even more pressing, and
>> my belief is that this requires a drastic change in the charter proposal.
>>
>> I gave a lot of thoughts to the following sentence, from the TAG review
>> : "we see an extremely broad problem space, and a single proposed
>> solution". I believe this summarizes the crux of the concerns raised
>> about the charter, but also points to a possible resolution. It is true
>> that the Solid community has huge ambitions (reframing the way web
>> applications are built and used, giving back the users control over
>> their data...). But what we want to get out of this WG is not a complete
>> and definitive answer to all of these ambitions. PR 62 [3] was an
>> attempt in that direction, but it might not be suffisient: neither in
>> terms of narrowing down the problem space, nor in term of broadening the
>> solution space.
>>
>> If I had to give an elevator pitch of the Solid protocol (i.e. the
>> expected deliverable of the proposed WG), it would be :
>> * a evolution of the LDP protocol
>> * + a standard way of authenticating users
>> * + a standard way of specifying access control
>>
>> So my idea is that, instead of pushing for a "Solid WG", why not propose
>> an "LDP 2.0 WG", chartered to produce 3 specifications : LDP 2.0
>> (client-server protocol), LDP-OIDC (authentication based on OIDC) and
>> LDP-AC (access control). The corresponding Solid specifications could
>> serve as a basis for these deliverables, but so could other similar
>> specifications (e.g. https://open-services.net/). Ideally, the resulting
>> specs would be entirely satisfying for Solid, meaning that a Solid POD
>> would simply be required to comply with the 3 new LDP specs. Possibly, a
>> few Solid-specific additions would be required, that could be specified
>> as a very thin addition (a profile ?) of the new LDP.
>>
>> Before I move forward with this idea and start drafting a new charter,
>> I'd like to know how this community feels about that?
>>
>> pa
>>
>> [1] https://github.com/solid/specification/pull/597
>> [2] https://github.com/w3c/strategy/issues/377#issuecomment-1790209071
>> [3] https://github.com/solid/solid-wg-charter/pull/62