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.
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.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
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. |
This comment was marked as resolved.
This comment was marked as resolved.
|
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. |
Previous draft had six subsections and fifteen bullets that were overkill for the guide's scale. Collapse to a single flat list of the four points implementers most need to know: - WebID integrity (solid:oidcIssuer server protection) - Authorization authorizes agents, not applications - Consent transitivity in access control - Client identity / no-secrets-in-SPA Drop the WAC leakage subsection, Preferences delegation bullet, profile-discoverability subsection, and the header-vs-body spoofing footnote — these are real but niche, and their spec citations give implementers a pointer if they need them. TOC simplified accordingly: §5 has no subsection entries.
There was a problem hiding this comment.
Omit : "Do not traverse further: discovery links in the documents fetched by this step, in extended profiles discovered from the Preferences Document, and in Type Index documents are not followed."
Add : Clients must descend two levels from the WebID document looking for extended profile links and may descend as far as they want. An author who places an extended document link in an extended document linked from the WebID profile should expect that second document to be read by clients. They can not count on links further away being discovered.
Note : I am not adamant about allowing extended document links in the type indexes and preferences file although I can think of many use cases for those. What I am adamant about is the ability to go at least two levels from the WebID document for extended documents other than the Preferences and Type Indexes.
Apply the three suggestion comments on PR #776: - Line 501: '(e.g. #me)' -> '(e.g., #me)' - Line 530: '(i.e. an unauthenticated...)' -> '(i.e., an unauthenticated...)' - Line 565: '(e.g. pim:storage...)' -> '(e.g., pim:storage...)' Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Per discussion on PR #776: defer to the Security and Privacy Considerations sections of the relevant sub-specifications rather than restate them here. Removes §5 entirely along with its TOC entry and the §3.1 cross-reference. Solid-OIDC third-party-issuer concerns raised by @csarven and the additional point about issuer-trust requirements regardless of issuer scale are being taken upstream to the Solid-OIDC spec.
Add a second bullet to §2.5 Solid WebID Profile flagging that most server implementations do not conform to the Protected Properties requirement, and the security consequence: an agent with write access to the WebID Document can rewrite solid:oidcIssuer and impersonate the WebID owner. Co-located with the existing Solid WebID Profile section.
- §2.1 access-control bullet: name the SAI Authorization Agent as a concrete example of an access-management Client (per @elf-pavlik on PR #776). - §4 data discovery note: hyperlink Solid Application Interoperability to TR/sai. Add an editor's note that a Type Indexes link will be added once PR #786 (which lists Type Indexes as a TR work item) is merged.
Replaces the prior linear procedure with a single set S of statements grown by repeated discovery-link expansion. Defines "user's WebIDs" as the original WebID plus the transitive owl:sameAs closure within S, and restricts discovery-link traversal (rdfs:seeAlso, foaf:isPrimaryTopicOf, pim:preferencesFile, owl:sameAs) to triples whose subject is a user's WebID. Type-Index fetch and final subject filter use the same set. §3.1.2 item 3 reduced to a single sentence pointing at §3.1.3; oidcIssuer caveat dropped here as the algorithm's authoritative filter covers it. WebID Profile dfn now defined in terms of the procedure. Adds notes on cycle detection / advisory depth limits, Preferences-link leniency, and entity reconciliation (augmentation vs rewriting). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds a parenthetical name to the cycle-detection / advisory depth-limit note, matching the naming style of the Preferences-leniency and entity-reconciliation notes. Lets external references point at the specific note rather than "the first note". Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
11 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).