Conversation
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
@elf-pavlik I am comfortable working in this PR for now, and directly pushing changes in response to comments. I will keep using small well-described commits so that the lineage of changes is easy to follow. @csarven I greatly appreciate the feedback, the majority I agree with and have implemented. The only thing I have not changed based on feedback is the leaving out of N3 Patch -- I respond to this below. I also have one question -- from the feedback I am unclear on whether to use (CG-Draft, VERSION) or (ED, VERSION) when referring to most pieces of the spec. In the pushed changes I have used CG-Draft everywhere. Could you please advise on whether this is correct.
The rationale for leaving it out is as follows:
There is not currently consensus on this, I propose making this a topic of the next CG call. If there is more to discuss on N3 patch asyncronously, now may be an appropriate point to open a separate issue. So that we can have that discussion in a focussed thread. |
|
In https://github.com/solid/solid26/blob/main/content.md#whats-included
https://github.com/solid/solid26/blob/main/content.md#relationship-to-linked-web-storage
I think there are already a lot of expected changes that we can signal. I'm not sure if this should go into this PR. |
|
@jeswr , Thanks for taking the feedback into consideration. Reminder re updating the references.
I think for solid26, it should use CG-DRAFT/FINAL because those are about as "stable" as it gets, and their timestamped snapshots are immutable references where one can ensure some precision on interoperability expectations. Take ED as WIP and subject to change. That said, EDs in the Solid CG for the most received enough support that their TR snapshots were fairly close to it (which IMO is a good thing). I think the way you have the Notes right now are good, giving concrete heads-up or waypoint but leaving it at that. (Remove the "Editor's" bit from the Note).
I can go along with anecdotal evidence for the sake of moving the discussion but it'd be appropriate to back this with some data even if it is incomplete. Which servers? Can you link to them? Did they provide implementation experience that's publicly accessible? Could we compile a list of servers to see which features they support with regards to patching, and if and how that's compatible with Solid Protocol?
Ack. But then again the Solid CG is not running on WG timeline. It is incubation space. It can virtually reference / lean on any open standard. The other concern about removing N3 Patch is that, then there is currently no patching recommended, not even SPARQL Update. I suggest to not dismiss N3 Patch in solid26. While if SPARQL Update can be updated is a worthwhile effort, there is no guarantee that it will happen or even in a timely matter. If pursuing N3 (Patch) is challenged, then SPARQL Update would be ass well. If implementations take up N3 Patch, then that's valuable feedback towards standards development - what more can be asked for than open source implementations giving input that "yes this is or isn't worthwhile, it worked or didn't or found it buggy or have security/privacy concerns or no we don't want to implement this because we have other opinions or options... we did most of it but wilfully violated this and that part because..." That's strong input to N3 / RDF development as well as Solid. (Aside: I don't have a horse in this patching "race". dokieli implemented both as far as client-side matters go, and switched as the Solid Protocol evolved. Provided implementation feedback e.g., at #711 (review) and #652 (comment) ). I find N3 Patch and SPARQL Update both equally attractive in different ways. ) |
Which references are you referring to -- I believe the WAC ones are correctly updated to the snapshot version?
👍 - done!
👍 - done!
Good call. I suggest we leave it to the end of the week before going out for data collection in case any other features crop up that we want to ask about at the same time (given we have already asked for data on WAC/ACP implementations -- I don't want to be contacting implementors 3-4 times if we want data on more features).
Yes, that was intended behavior. Happy to discuss this in the CG call tomorrow. |
@csarven's steer in feedback has caused this document to become strictly the spec snapshotting and implementation guide based on the snapshot. I think this is a good focus and the suggested signposting belongs in a separate document. |
Fine with me, can we already start that separate document? Will Solid 26 manifest in just those two documents or there are going to be more of them? |
|
Should solid26 recommend more items from https://solidproject.org/TR/ to give a fair representation of what is relatively widely implemented and deployed? For instance, taking the data from https://jeff-zucker.github.io/solid-load-profile/ as one source of input, we can infer what's out there in the ecosystem and use that for the implementers guide. I'll let the group be the judge of how to make a cut (e.g., based on count or other criteria) for what's reasonably deployed. I think it is hard to argue against the fact that Solid WebID Profile and Solid Type Indexes are used out there. If solid26 doesn't suggest anything beyond a WebID, it downplays personalisation and the social aspect of Solid, and if anything, looks strange for the state of things in 2026. If there is other concrete data on the ecosystem, let's have a look. |
You know, the References, like: [SOLID-OIDC] [SOLID-PROTOCOL] [WAC] By the way, in solid26 you have:
But TR/oidc is not a "CG-DRAFT/FINAL" (nor can it be both). The latest published version is the one I referenced above: TR/2022/oidc-20220328. CG-DRAFT is only incorporated into its ED: https://solid.github.io/solid-oidc/ . An immutable snapshot version of that should be created at And if that new version is used for solid26, also update the editors of Solid-OIDC reference in solid26 accordingly since there is a change in the ED (after the TR/2022/oidc-20220328 release). Use "CG-DRAFT" instead of "CG-DRAFT/CG-FINAL" in:
|
|
There should be a general recommendation that latest published versions of specifications should be used. That could be expressed along the lines of: at the time of this publication we recommend x but implementers are strongly encouraged to use latest published when available, and if you like to live on the bleeding edge, use the editor's draft. On that last note, solid26 should also take the opportunity to thank implementers (somewhere upfront like in the Introduction) for helping to improve the Solid ecosystem, and any feedback on their implementation experience in meetings, issues etc., would be most appreciated. |
That's incorrect. "Clients" framing is red herring. The Solid Protocol has the requirement on the server in https://solidproject.org/TR/2024/protocol-20240512#server-wac-acp
The conclusion in the CG was that ACP should not be recommended based on WACvsACP data. The recommendation in solid26, at the very least, is about the removal of that requirement from servers. The language should emphasise what's recommended / encouraged to implement and discourage what not to implement. So, the text should say "ACP is not recommended" or "Servers are not required to conform to Access Control Policy (ACP)." re 286e7c7
I'm not sure if this is meaningful or if it is even necessary to mention. It could also be interpreted as quietly legitimising non-conformance. I suggest dropping it. re b5625db The section on #webid should be part of the #specifications section and reference both WebID and Solid WebID Profile specifications. If there is publicly accessible data, in addition to the one I've linked to above (Jeff's solid-load-profile), that can help to assess things, we can have a look. Otherwise, I suggest we don't venture too far off Solid CG's consensus. |
If we take this plus Soild 26 adding (non-normative?)
We seem to already get that ACP is not required for servers. I think it depends if this document tries to monkey patch referenced specs or offer more narrative guidance. To monkey patch I don't think there is need to add anything about servers and ACP. For the later it may make sense to discourage from implementing ACP. |
|
I would like to propose that we get this PR merged by the end of this week and @langsamu creates a draft PR based on his work on WebID guidance. We have only 2 CG meetings left before the Solid Week! |
|
solid26 is not a CG standard or specification in its own right. It is quite literally an implementers guide that waypoints to the most widely implemented and interoperable versions/slice of existing Solid specs, and to cut through confusion/annoyance. Reflects CG consensus on what the majority of the ecosystem has actually built and deployed. It does not amend or override referenced specs. It signals where to focus implementation effort, and that signal should be grounded in data and consensus (always!), not in accommodating outliers or opinions. I suggest that solid26 should not use requirement level language but rather advisory language (e.g., https://solidproject.org/ED/protocol#advisement-levels ). For example: Servers and clients are encouraged to implement WAC, which the ecosystem has converged on. ACP is discouraged. I would like to propose that we merge only what is grounded in CG consensus and backed by data. That applies equally to the access control question and to any additions around WebID and Solid WebID Profile, both of which have concrete ecosystem evidence supporting their inclusion. |
At this point I can't clearly tell which parts of this PR are ready to merge and which still need more work. I think it would be easier to merge parts that are ready and work on the rest in separate PRs. If we start making PRs on PRs and make changes to all of them it can get messy. @jeswr since last CG meeting before SoSy will be in less than 2 weeks. How much time you have allocated to complete this work? I think it would be great to have something ready that can be sent out to the CG mailing list sometimes next week, let's say after the next CG call. This way we can gather and address broader feedback and still have last CG meeting fully dedicated to resolve any outstanding issues. |
|
I'd rather we not compress the review process to fit a self-imposed timeline. Quality and consensus should set the pace here, not the calendar. If having this ready for SoSy was a priority, the work needed to start sooner. Rushing it now just trades one problem for another. Also, @elf-pavlik , this is the second time in a row you raise the two-week timeline in response to a comment/feedback. We heard it the first time. Repeating it doesn't change the review status of the work. It just adds pressure to move past objections rather than address them. I also want to flag a pattern worth being mindful of: when things get rushed under deadline pressure, the bar for what gets merged tends to drop, and then the people raising legitimate objections end up being framed as the obstacle. We've seen that dynamic before, and I'd rather not repeat it. |
|
The guide looks useful, thanks for putting it together. One concern: the note about updating the WAC reference to include PR #134 if merged in time. That PR still has unresolved security concerns around condition evaluation in mixed-capability deployments, including silent privilege expansion when authorization conditions are not enforced. I'd suggest Solid26 reference the stable WAC 1.0 snapshot (2024-05-12) and note that condition support can be considered in a future release once the evaluation model and versioning story are resolved. That avoids presenting a contested authorization design as the recommended baseline. For context, JSS and VisionClaw already implement conditions with fail-closed evaluation semantics in deployed systems. To my knowledge, no server currently implements the evaluation model proposed in #134. |
5 participants
This is the beginning of the implementors guide discussed in #773 - currently it just fixes the specs and versions to be included.
Additional specs such as #774 (which I acknowledge I still owe a response to) may be added to this guide if developed and CG endorsed in time.
A preview link can be found here.
EDIT since there is a lot of active editing on this PR -- I am marking comments as resolved as I implement changes to ease navigation (cc @csarven @elf-pavlik - I hope this is ok, as far as I understand anyone with read access can still expand and read the content as they desire).