diff --git a/meetings/2026-04-15.md b/meetings/2026-04-15.md new file mode 100644 index 00000000..b3dd8fa4 --- /dev/null +++ b/meetings/2026-04-15.md @@ -0,0 +1,193 @@ +# W3C Solid Community Group: Weekly + +* Date: 2026-04-15T14:00:00Z +* Call: https://meet.jit.si/solid-cg +* Repository: https://github.com/solid/specification + +## Chair + +* [Christoph Braun - uvdsl](https://github.com/uvdsl) + +## Present + +* [elf Pavlik](https://elf-pavlik.hackers4peace.net) +* [Jesse Wright](https://jeswr.org/#me) +* Alain Bourgeois +* [Luke Dary](https://w3c.social/@lukedary) +* [Roberto S.K. Breitman] +* [Rui Zhao](https://me.ryey.icu) +* Sarven Capadisli +* [Samu Lang](https://github.com/langsamu) +* Tim Berners-Lee +* [Erich Bremer](https://ebremer.com) +* Andrealiz + +## Regrets + +--- + +## Scribe + +* [Jesse Wright](https://jeswr.org/#me) +* [Christoph Braun - uvdsl](https://github.com/uvdsl) +* [elf Pavlik](https://elf-pavlik.hackers4peace.net) + +### Meeting Guidelines + +* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar). +* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md). +* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur. +* Join queue to talk. +* Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed. + +### Participation and Code of Conduct +* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/) +* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Conduct](https://www.w3.org/policies/code-of-conduct/) +* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome. +* If this is your first time, welcome! Please introduce yourself. + +--- + +## Introductions + + +## Announcements + + +## Topics + + + +### Action review +* eP ✅ to schedule Luke's demo for next week + + +### Demos + +#### Oxigraph Cloud-Native +https://github.com/chapeaux/oxigraph-cloud +* LD: I have been used Oxigraph as the storage for Solid, and added some features Oxigraph did not have. This snowballed to a horizontally scalable, cloud deployable project. +* ... I started with the ability to add rudof SHACL ability. +* ... I had a RocksDB backing database. I then extended that to extend the number of Oxigraph servers available that are not going to run into conflict. +* ... It runs just like Oxigraph, with the ability to do SHACL shape validation along the way +* ... I also added telemetry with open telemetry +* ... It is probably not going to production in any way +* ... I put a blog post of my findings at chapeaux.github.io/blog/sparql +* ... Someone [Erich Bremer] in the OS tooling meeting mentioned https://chapeaux.github.io/blog/sparql/ [qleverdb](https://github.com/ad-freiburg/qlever) which has better performance. So I am moving from this project to something similar using [qlever](https://github.com/ad-freiburg/qlever). +* JW: What was the original goal with respect to Solid? +* LD: There didn't seem to be a good foundational data-store for Solid that is a foundational RDF datastore. There isn't what I would call an enterprise grade RDF data store that supported the features of Solid where you could go "if you deploy this, that will essentially be the features of Solid." I want to e.g. be scale it as you have more Pods. +* eP: In my implementation I have extended CSS so that all RDF goes into a SPARQL endpoint, so that it goes together with the blobs to a SPARQL endpoint. I would like for the user to be able to provide a Pod and point to an S3 bucket in CSS where this would be stored. Have you looked into setups with isloated tenants like this? +* LD: I did somewhat look into that. From a scalabilty perspective I didn't hone in on that, because it seemed to increase the load. If you have 1000's of users and they logged in at the same time that would drive the processing requirements up. +* LD: If the processes are ephemeral and can be spun up and down, they may be ephemeral as well. If I am trying to do any type of hack and break the system it didn't work well if it was all bundled together. +* LD: The RDF and binary split is problematic to handle. It doesn't seem like there is a good out of the box handler for that specific interaction. +* eP: There is no content negotiation. If you need RDF in combination with a resource then you need a description resource. +* JW: If you have SPARQL endpoint query of the data, do you have authorization on that endpoint? +* LD: There is a SHACL shape validating the WebID... I will post how I do it +* JW: This sounds like AuthN not AuthZ, can I turn up to the SPARQL endpoint with an access token and get a response which is a result over the subset of resources I have access to. +* LD: I believe so but need to check. + +### Solid26 +https://github.com/solid/specification/pull/776 + +* JW: Have been talking about this for a couple of months, where Solid26 aims to increase adoption by marking fixed versions of the different specifications in the Solid Protocol, to include implementers feedback, and ... +* ... for today, some open threads remain, so we might want to discuss this here. +* ... rather than making it an opinionated document itself, it could just point to fixed versions, and point to existing implementations such that implementers can find a solution that works for them +* ... CB had given feedback on N3 patch, similar I provided similar wording for other parts +* ... SL is working on WAC/ACP document +* ... there is an open question on N3 patch, re recommended fallback. +* ... there is also a suggestion from SL on wording regarding around authorization +* eP: What is the approach that the document wants to take? +* ... re Solid-OIDC, we are planning on creating a snapshot of what works right now +* ... but then, there were some normative statements that looked like monkey patching +* ... maybe take a step back and see what we want to do here exactly. +* JW: I thinkn CB's comment is the correct strategy +* CB: It was in line to work with Solid Protocol as is, so not to contradict it. Instead to say what the protocol requires and explain what most implementations do which is within bounds of solid protocol. So remove the normative language but keep the guidance. +* SC: Regarding access control, the whole discussion was already concluded in the CG based on the data gathered in the CG, which was that implementation of WAC is encouraged and ACP is not. Anything else does not reflect community consensus. Anything else, that e.g. clients should do this or that, is out of scope here. There were also some mistakes that were corrected re clients implementing. I object to the language around the wording that was or is in the PR. I maintain that (along those lines) WAC should be encouraged and ACP not. +* ... re N3 patch, while some servers might not implement it, this PR is not the right place to discuss this. We were talking about what a conforming server should do within the bounds of the protocol. Not exploring what access requests could be do here. +* ... the PR was opened 2 weeks ago, and I do not appreciate that there was a rush to get it merged, especially considering that as soon as constructive feedback was given, the initial feedback was dismissive pointing to running out of time. +* eP: My interpretation is that if a client is managing access, then a client must implement both. So my question is if Solid26 may recommend NOT conforming to specific requirements from referenced specs. +https://solidproject.org/TR/protocol#client-acp +>"Clients MUST conform to the Access Control Policy specification [ACP]." +* JW: re N3 patch, I have no strong opinion on SPARQL update. I recognize that it is not in the Solid Protocol. I was looking for some text that we could include that enables features closer to N3 patch. Point is, I am happy to go with closer what CB said and not to push for SPARQL update. +* ... re access control languages, I think there are two open threats: +* ... 1. how we frame this document as a whole +* ... if we follow the philosophy of CB, saying that we look at the Solid Protocol and fix some versions in Solid26 and reflect on the state of current implementations, then I would be leaning on the new text I proposed where I say that the Solid Protocol requires ACP and WAC, clients typically only implement one. That is more inline with not including any normative language, so it does not break anything from the Solid Protocol. +* ... It was also pointed out that there were some flaws in the data collection, e.g., as raised by SL in an ODI internal call, which is that there is no reflection of where particular servers and apps are deployed and what their usage is and number of usage is. We do have some data but ODI thinks that the data does fall apart quickly. +* SC: If the group wants to go back to the drawing board to gather new data, then I suggest to come up with transparent criteria so we can all agree on what to rate the data. I am open to that. As it stands, we can split hairs about the above properties. You mention Technology Readiness Levels (TRLs) which seems to be a loaded term. Readiness for who or where? What context? Ready for the "Open Web"? Accessible to different people, regions, economic backgrounds? Open source? +* ... I have to be honest. Looking at the data, and how now the PR and its content have been handled, it seems that someone in that discussion did not seem to like the outcome. Still, I think that the data is the best overview of what is out there that we ever had. +* ... there has been multiple pushes for ACP to become the only Access Control Language, which had not been successfull, and the data seems to reflect that +* ... WAC remains prominent in the ecosystem, and actively maintained +* ... if ACP is actually used, why do we not hear from implementers or deployments, why do we not get feedback to benefit from. +* SC: I would thus like to propose to remove ACP from the Solid Protocol altogether. PROPOSPAL: Deprecate ACP in Solid Protocol +* ... This is independend from the Solid26 discussion, we can have that discussion as well. +* ... Still, my proposal stands. There is also additional implementations of WAC which we also did not cover, e.g., from OpenLink, W3C, and others. +* ... I think we should acknowledge what worked and what didnt. +* ... There were also folks in the community that advocated that we do not need ACP, Henry Story did infact showcase how WAC can facilitate the same use cases of ACP. This discussion then stalled due to lack of engagement from the ACP camp. So, why dont we just settle on WAC? +* eP: The next topic would be relevant to assess how mature / engaged a specification is. +* ... re data gathering, I think there is alot of room to improve that process. +* ... re timeline, I was under the impression that CG generally wanted to work with ODI on Solid26. But given the dissent, what do we do? At this point, I dont find it realistic to find consenus in one CG meeting left. +* ... lets have a realistic plan, e.g. state that it is a work a progress. +* JW: On timelines. What I propose is that we work to have pens down on monday, and sent a mail over the mailing list. The process of 5 days at least of feedback time. +* CB: I would actually recommend just sending out call for feedback now over the mailing list. It would not make difference if feedback comes now or day later, we can get people engaged already. PR needs to be open at least 5 days it doesn't imply that it will be merged. If there is not sufficient consensus it will not be merged. With remaining descent I would be hesitant to merge it. +* JW: Happy to sent out a mailing list. I agree that if there is dissent, we cannot merge it. In which case, I think that eP's suggestion is good - announce it as still being finalized. +* SC: As long as the document's content reflects the consensus of the CG, so maybe lets fix that first. +* CB: I retract my suggestion to send out an email now, and support the suggestion by JW. +* JW: I wanted to echo eP's opinion. We are setting up feedback infrastructure to gather better data. I would like to propose soften the wording and to use Solid26 being the vehicle to gather wider data. +* CB: I want to emphasise that there are different audiences that ODI has in mind. From what we have right now, the recommendation for one over the other is pretty obvious. However the wording in the end is, it cannot put ACP as the prime policy language to use, just based on the feedback gathered. +* ...: For the Sarven's proposal I would say open an issue and get feedback from community. I wouldn't tie it to Solid26. +* JW: I agree with you, to not recommend one over the other. Samu proposes language how to map one to the other. Is there any issue around the discussion about access requests. +* eP: +* TBL: As a meta question, weather CG can produce a statement by the deadline. A text is being proposed that would be generally helpful to community. If nothing can be said about Solid without getting consensus from the group. ... CG becomes ... futon for the community (???) +* ...: For the particular issue of ACP/WAC, WAC is much more deployed but not mentioning ACP would be injustice because it exists. +* ...: and mathematically ACP is a more powerful languague. It can do things that WAC cannot do +* ...: as an analogy pop and imap. pop is much simpler but both exist and you can use both, but one is much more powerful. +* ...: There are interesting ideas about whether WAC could be extended to have the features of ACP as well but that is not in place yet. +* ...: Can the CG get to a point where it can endorse this document where it will be useful in time for the Solid Symposium. To an extent it was proposed as a useful thing to have during this Solid week. So if the document would be useful coming into the community -- after all it is non-normative, it shouldn't be a very high bar to get content in. If this group cannot agree to the existance of ACP and WAC then it is a shame and someone should put it out as an unendorsed document or something. +* SC: Again, we can come up with criteria and re-evaluate. I dont know if the complexity of the technology is favorable here. +* TBL: What you just said was too general for me to udnerstnad. Can you be specific on what is meant by "a complex technology is not necessarily favourable here." +* SC: At the end of the day, we want this thing to be implementable and to get feedback from implementers. WAC has a better track record here. I dont know what new criteria would be needed to make ACP appear better +* ...: WAC and ACP are not that different when you dive into the model. Different environments need different things. When we look at the open web or social web -- WAC quite literally gives us what we want. This is better than offering something complex that doesn't have the same foundation. If you look at google docs, their interface boils down to read/write/append and control. This is from one of the largest tech companies with a userbase of billions. That is working for that type of environment. I feel that we aren't aiming for that 80-95%, instead we are looking for that 1% that we are trying to optimise for somehow. +* ...: We are 10 years into this project. Where are all the applications? Solid has not yet revolutionised the world or fixed the web and we are arguing about the finer details about WAC and ACP, when we should be getting something good enough out the door, and when we have enough people around the table and people to implement it, then yes - we adopt those things. +* ...: I/We did some work to better understand [how different authz frameworks could work in Solid](https://github.com/solid/authorization-panel/issues/121) for different uses cases. If we look at the Solid vision the solution space is much broader than WAC and ACP, which are essentially just ABAC and we are not even talking about capability-based models for instance. We are also still stuck with things like Solid-OIDC, we are stuck with a (third-party) identity provider that we don't necessarily control and can be taken away at any time. We are putting all of our eggs in one basket and something is going to break somewhere. Many people under the same origin are going to lose access to their identity on the Web. I find it strange that we are debating on these things. We should ask - is WAC giving us 80-90%, if not 95%, of what we want. Is it covering everything under the sun, no, but we should be getting from A to B and then B to C. We have had time in the CG, to incubate WAC in the CG not ACP. On access requests I thought the goal of Solid26 was to talk about what is out there today. The only thing that is close in the CG is SAI's approach to access request because it is a recommendation in the CG - not things that are not incubated, that some WG is working on from scratch. We don't know what TAG will say, we don't know who will implement it. It is further behind than SAI is or other solutions with Inboxes. We should be looking at what is in front of us, not looking too far ahead at what implementations should be doing. We have not eaten our own dog food enough to back it up. Let alone getting on with our own things. The ones that show up, the one who's voice is louder is the one who gets their voice in the group. I don't know if those few voices are better for Solid than looking at a consensus but usually not. I don't want to talk about hypotheticals - especially for Solid26. What can we honestly or modestly tell others about what Solid is or can do. +* CB: I want to acknowledge the feedback from both of you. Especially the question of whether the CG can agree on an implementors guide. Whilst I see where you are coming from, and why this is useful to help foster adoption and spread the word. I am deeply concerned about repeating the mistakes that have been done in the past regarding how Solid had been marketed to different groups by various stakeholders, which were not aligned because there were various groups advertising it to various to stakeholders. My hope with ODI taking stewardship is that we can find a common narrative for Solid, so that I don't have to re-explain Solid to people in German industry because they have an initial impression based on other narratives. This document is key to finding that joint ground narrative -- basically like finding that smallest common denominator. If we don't do that I see 2020/21/22 repeating all over again, and I don't want to witness that. If ODI puts out a separate document under its name that is fine, as long as it not marked as endorsed by the CG, the same as we do with universities when we put out our own additional explainers of the technologies. +* ...: On WAC and ACP I do think that we should encourage WAC over ACP given what we have heard so far from the community, given that it supports a wide range of use cases and that it is extensible to support a wider range of use cases. I am yet to encounter a use case that WAC does not support directly or through the extensions it allows. I am yet to see an application in Germany which uses ACP. Further, because WAC is so simple, it is much easier for people to extend WAC with the concepts that they need rather than ACP. +* ...: On access requests I think that pointing to what is already there is sufficient for Solid26. +* Tim: Does anyone object to having ACP mentioned? +* SC: I object since we gathered the data and made a decision earlier. +* ...: I base my objection on intent to sticking with some form of a process. Why we don't follow what we agreed to do? Maybe CG should recommend capabilities? +* Tim: That was just an attempt to get the agreement from this group. +* JW: I want to respond to statement about the reason. I implemented the data collection which was flawed. +* SC: What's the new process or criteria? +* JW: Because we work on infra for better data collection. From end of April for 3-6 months. Until then we deleay any form of recommendation and let implementers work with both. For Solid26 I would suggest that we don't push eaither way. +* RZ: Me personally I've seen situations where WAC is not complete and I'm inclined to ACP. With extension being worked on that applies client restrictions... It is weaker thank ACP to accept as Solid26 recommendation. I agree with Sarven that we need to stay on the same evaluation criteria. I guess to me I'm willing to make a special case for authorization decision, especially with the features that are asked for. +* CB: That's an interesting thought, we can entertain it in the wider Solid Protocol discussion. Focusing on Solid26. Can we work with the data that we obtained, and acknowledge that we have it as it is. Being WAC is widely implemented ACP less: implementers be aware. And note that this is an attempt of gathering broader feedback from implementers. I see that you want to use Solid26 as a vehicle to obtain feedback. Let's acknowledge the data we have and consider it as the first iteration. +* JW: There are WAC and ACP and you can view implementations of each here (link). From the data collected we have seen 13 servers implementing WAC and 2-3 implementing ACP. The quality of those implementations is not known at the time of writting. +* CB: ... +* SC: I don't understand the feedback you want to ask for from implementers. +* CB: Here is current data (link), if you happen to be an implementer and provide feedback, call Roberto. +* SC: I understand that we can come up with resons for it. I look forward to agree on criterias. +* RB: We plan to gather feedback and funnel it into the community. Especially the server implementations. Doing it in more scientific way. We can also have something we can help implementers with. I have reason to believe that whatever we run throught this process can be more successful. +* SC: We don't have test suite for ACP, stability and correctness is not even possible. I want to know if the ODI or CG wants to take on that task and ask ESS (implied) to implement WAC. They are not even conforming to the Solid Protocol. Unless that story changed I want to know what are we aiming for? or optimising for? There is a range of things. I know that. We should try to get implementers aligned so that the ecosystem is richer. In fact, there is already alignment in the ecosystem. Vast majority are aligned around WAC. It is the outliers here that's the concern, and they should align with the rest of the ecosystem. +* ...: I dont want to optimize +* TBL: I want to point out that re relation WAC and ACP. they are different. WAC is RDF, it is monotonic. If you add or remove triples, it remains true. +If your system gets sufficiently complicated, then you need ACP because you can deny things. SC said that we should encourage WAC over ACP. +For some problems, WAC is sufficient, indeed. +ACP is more complicated. You can extend WAC to a certain extend, e.g., client ids, and WAC will still be monotonic - but their are quite different design in the mathematical sense. +* SC: I agree with everything you said, this is my understanding of these technologies as well. If we take everything we can from the data, which is only a sample, then it seems that the deny aspect of things is not in such high demand. There might be different reasons - maybe people did not hear about it or not enough marketing. I dont think that this feature is required to the vast majority of use cases that we want to facilitate. If you look at Google Docs or Drive, the UI really boils down to what WAC can do. Of course, there is more behind it for Google, but the UI offers the functionality akin to WAC. But indeed, maybe in certain environments, e.g., for admins or others, functionality of ACP is required, and this is fine. But I think our focus should be on the broad. + + +### Diagram for policy stages to contrast different policy languages or engines  +https://github.com/hackers4peace/sosy26/issues/3 + +* RZ: Basically, this is an example where we try to compare different policy languages and policy engines across different dimensions. +* ... these are just the ones I know - if others are working on other engines or languages, happy to include them. +* ... so there is e.g. WAC and ACP and also ODRL. +* ... different policy languages do different things so there are different rows. +* ... WAC and ACP are grouped together because in general, they do the same thing on access control +* eP: I think it is an interesting approach to break down different works and see which features are supported. This could be a good way to evaluate different approaches, a framework. Let's pick this up after SoSy. + +## Actions +* eP to schedule Rui's demo for 2 weeks from now + +## Decisions +