feat: initialise Solid26 implementors guide

[jeswr]

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).

[elf-pavlik]

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?

[csarven]

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.

[csarven]

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.

[jeswr]

This guide should include some basic security & privacy considerations.

Done in 7be1a87 — new §5 Security and Privacy Considerations with six subsections sourced from the pinned specs. @elf-pavlik Your two points are in §5.2 Application Authorization (WAC has no app-constraint mechanism, Origin isn't client identification; ACP Client matcher has limited coverage in practice, with your video linked). Section flagged as AI-drafted for kickstart; please flag anything to expand or soften.

[elf-pavlik]

I'm not sure what do you mean by anonymous clients. Leaving aside dynamic registration, which OIDC Provider is not required to support, provider/issuer verifies cilent identity by checking redirect_uris in Client ID Document. Authorization Server / Resource Server relies on what issuer asserted, so unless issuer is restricted in access policy end user could technically set any client id they want. With token exchange / UMA, there could be client authentication on token endpoint, for example using JWT assertion. This would not work for public clients, but traditional web apps (with backend) which are confidential clients could authenticate themself properly.
There is a broader issue when authorization sets client condition/matcher, who is allowed to assert it after some verification, options are.

• end user's issuer - technically end-user could set any client id they want
• resource owner issuer, so besides client condition/matcher there would also be issuer condition/matcher
• authorization server - possible with token exchange / UMA and confidential clients, client id asserted by the issuer wouldn't need to be relied owner

LWS should do proper threat modeling that would take all such variants into consideration.

[elf-pavlik]

SAI Authorization Agent is another example. I have old demo where user can select resource in the app and get redirected to authorization agent to share access to that resource with other's in user's social graph.

• spec: https://solid.github.io/data-interoperability-panel/specification/#authorization-redirect-endpoint
• primer: https://solid.github.io/data-interoperability-panel/primer/application.html#resource-indication
• short demo: https://www.youtube.com/watch?v=IXzdH1JqcOA

[elf-pavlik]

Another flow I want to implement would use access request and either

• redirect to authz manager if something like PAR https://www.rfc-editor.org/rfc/rfc9126.html is used
• send push notification to authz manager PWA and handle sharing user interaction this way.

[csarven]

This is negative information. The encouragement for implementers should be about taking care of this or the next steps. Literally encourage existing or new servers to do something here, and not just complain.

Once again:

if we are dropping down to this level of scrutiny, because some deem it to be a necessary criterion of sorts, then we should certainly apply that consistently across every specification mentioned in solid26, including those that do not have significant uptake, and whether each feature in their specification has a test and a publicly verifiable implementation implementing it. If not, there should be strong advisory against using those specifications.

#781 (comment)

[kaefer3000]

How about https://github.com/solid/specification/pull/776/changes#r3137772237 @csarven

[csarven]

Yes, that suggestion does improve.

[csarven]

Once again, this is undermining/underselling WAC. Are you aware that the conditions feature (including the possibility to indicated clients and issuers) is now in WAC ED: https://solid.github.io/web-access-control-spec/

All we are waiting for is some implementations before it is part of TR/wac . @uvdsl and I are working on separate implementations.

So, it is not unimaginable that what's written will be obsolete will probably be outdated by the time this document is published. Perhaps worth reflecting on that.

See also #783 (review)

[csarven]

The meaning depending on the "integrity" of its Profile Document doesn't really say anything deep or useful to the implementer. At best, it is no different than the URI owner allocating a URI to resource, and describing the resource.

Are you trying to say that when a WebID is hosted by a Solid server its integrity is questioned because it may not be able to protect some statements? So, this is your way of saying don't host your WebID on a Solid server. And also saying Solid doesn't make it possible for people to control their identity online. That seems to run against the fabric of the Solid project.

In any case, this is fixable or can be improved upon. It is fundamentally no different than protecting containment triples (as mentioned in Solid Protocol), or possibly consider looking into alternative authentication mechanisms so we don't need to bother having oidcIssuer in a Solid WebID Profile.

[kaefer3000]

How about https://github.com/solid/specification/pull/776/changes#r3137772237 @csarven

[csarven]

Yes, that suggestion does improve.

[csarven]

That explanation seems inadequate. It seems to cherry pick in such a way as if there is something "bad" about WAC. Here is the full quote from https://solidproject.org/TR/2024/wac-20240512#security-privacy-review-personal-data and it is important to understand what's actually being expressed here. It is trying to be considerate about all sort of things for the implementer in a meaningful way.

ACL resources can contain any data including that which identifies or refers to agents and agent groups. Access to ACL resources is only granted to Access Subjects with the acl:Control access mode, and thus by definition, meaningful consent to any personal data that agents include about themselves is extended to other agents with control access on the ACL resource. Group resources are subject to the same Authorization conditions as any resource (that is not an ACL resource), and thus information could be exposed.

And mind you that WAC at least has a security and privacy considerations section, something ACP does not even have, so its fitness is highly questionable. That should be captured in this section about all sorts of potential problems in ACP. See also #783 (review)

[csarven]

While SPARQL or QPF may be used out there, they are not incorporated in the work items listed in https://solidproject.org/TR/ .

If we are going to explain other things that's happening in the ecosystem, then lets bring out the laundry list. I would like us to come back to this point as to what qualifies here and what doesn't.

[csarven]

One of the points that should be made about Solid-OIDC in the security and privacy section is about third-party issuers. It should address considerations on:

• What it means for implementers to rely on third-party issuers in the context of Solid promising users to control their identities?

• The security and privacy risks with regards to many agents using the same issuer, and the danger of that issuer being a single point of failure for all agents using them. So, when the issuer is compromised, this is a massive problem. Attacks tend to focus on major centralisations, so this is a concern for implementations offering multiple accounts. Similarly, the service could perform illegal activities.

[kaefer3000]

Suggested change

<li><strong>WebID integrity.</strong> The meaning of a WebID depends on the integrity of its Profile Document. <cite><a class="bibref" href="#ref-webid-profile">Solid WebID Profile</a></cite> § <a href="https://solid.github.io/webid-profile/#protected-properties">Protected properties</a> requires servers to protect <code>solid:oidcIssuer</code> triples from non-owner modification; not all servers do, and on such a server any agent with write access to the document can change the issuer.</li>

<li><strong>Protected Properties in WebID Profile Documents.</strong> Servers should protect the § <a href="https://solid.github.io/webid-profile/#protected-properties">Protected properties</a> in a <cite><a class="bibref" href="#ref-webid-profile">Solid WebID Profile</a></cite> document such that non-owner agents with write access to the document cannot change the issuer.</li>

...to avoid the word "integrity" and remove the side note about what current servers often do not do.

[csarven]

That works, thanks. Minor: consider replacing "should" with "strongly encouraged".

[jeff-zucker]

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.

[jeff-zucker]

Line 574 directly contradicts line 565 and line 581 and introduces a much too restrictive set of bounds. The minimum set of bounds is, in my opinion, 2 traversals. This mandates nothing about the writability of any document, only that if there are links in an extended doc to other extended docs we should be expected to follow them at least one level, i.e. two levels from the WebID Document.

Here are two examples of what a limit of one link would prevent

   <WebID1> rdfs:seeAlso <friendsAndFamily.ttl> .
   <friendsAndFamily.ttl> rdfs:seeAlso <familyOnly.ttl> .

When permissioned accordingly, this pattern allows family to see the more general friendsAndFamily data and also the more specific family data, i.e. inheritance. Why would we want to prevent that kind of security structure?

Also prevented by a limit of one

   <WebID1> owl:sameAs <WebID2> .
   <WebID2> rdfs:seeAlso <myCV.ttl> .

With a limit of one, a discovery of WebID1 will not turn up myCV.ttl.

A limit of one greatly limits the freedom of users to partition and control their data.

This limit is in contradiction to the WebID Profile Draft and the drafts which preceded it and is being introduced at the last minute. Either drop the limit entirely or make it two levels.

[jeff-zucker]

This introduces a completely unnecessary split between types of servers, requiring clients to follow differing expectations. It adds complexity to discovery. It allows the Identity server's decision on storing the WebID to control the ability for discovery on the Resource server and takes capabilities away from WebID owners. Why should we have to tell clients "If you're on server A, do B, but if you're on server C, do D?

[jeff-zucker]

Also, this completely contradicts line 574.

The one level of traversal from Extended Profile Documents in Solid storage lets a client attach further Extended Profile Documents (for example, at different access levels) via links it can write.

No, if clients are only expected to descend one level from the WebID Document this advice is useless since clients will never follow those links.

[TallTed]

Suggested change

The WebID Profile Document is obtained by dereferencing the WebID HTTP URI: for a WebID with a fragment (e.g. <code>#me</code>), the fragment-less URI identifies it; for a WebID without a fragment, an HTTP <code>GET</code> MUST return <code>303 See Other</code> whose <code>Location</code> identifies it [<cite><a class="bibref" href="#ref-webid">WebID 1.0</a></cite> § <a href="https://www.w3.org/2005/Incubator/webid/spec/identity/#terminology">Terminology</a>, § <a href="https://www.w3.org/2005/Incubator/webid/spec/identity/#the-webid-http-uri">The WebID HTTP URI</a>].

The WebID Profile Document is obtained by dereferencing the WebID HTTP URI: for a WebID with a fragment (e.g., <code>#me</code>), the fragment-less URI identifies it; for a WebID without a fragment, an HTTP <code>GET</code> MUST return <code>303 See Other</code> whose <code>Location</code> identifies it [<cite><a class="bibref" href="#ref-webid">WebID 1.0</a></cite> § <a href="https://www.w3.org/2005/Incubator/webid/spec/identity/#terminology">Terminology</a>, § <a href="https://www.w3.org/2005/Incubator/webid/spec/identity/#the-webid-http-uri">The WebID HTTP URI</a>].

[TallTed]

Suggested change

<li>Form the set union of statements from the fetched documents, then drop every <code>solid:oidcIssuer</code> triple that did not originate in the WebID Document: that predicate is authoritative only when sourced there, mirroring the write protection in <cite><a class="bibref" href="#ref-webid-profile">Solid WebID Profile</a></cite> § <a href="https://solid.github.io/webid-profile/#updating-profile">Updating Profile</a>. Other discovery predicates (e.g. <code>pim:storage</code>, <code>ldp:inbox</code>) may legitimately appear in any of these documents.</li>

<li>Form the set union of statements from the fetched documents, then drop every <code>solid:oidcIssuer</code> triple that did not originate in the WebID Document: that predicate is authoritative only when sourced there, mirroring the write protection in <cite><a class="bibref" href="#ref-webid-profile">Solid WebID Profile</a></cite> § <a href="https://solid.github.io/webid-profile/#updating-profile">Updating Profile</a>. Other discovery predicates (e.g., <code>pim:storage</code>, <code>ldp:inbox</code>) may legitimately appear in any of these documents.</li>

[TallTed]

Suggested change

	The WebID Document is a public resource (i.e. an unauthenticated HTTP <code>GET</code> on the WebID URI returns the Profile) [<cite><a class="bibref" href="#ref-webid">WebID 1.0</a></cite> § <a href="https://www.w3.org/2005/Incubator/webid/spec/identity/#processing-the-webid-profile">Processing the WebID Profile</a>].
	The WebID Document is a public resource (i.e., an unauthenticated HTTP <code>GET</code> on the WebID URI returns the Profile) [<cite><a class="bibref" href="#ref-webid">WebID 1.0</a></cite> § <a href="https://www.w3.org/2005/Incubator/webid/spec/identity/#processing-the-webid-profile">Processing the WebID Profile</a>].