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.

[elf-pavlik]

This guide should include some basic security & privacy considerations. For example that WAC has no reliable way to authorize applications (assuming PR for conditions doesn't land) and ACP has only limited way of doing it for one's own resources as demonstrated in https://youtu.be/5Q1nUmGdaXE

I think it is better to clearly communicate about known limitations up front. Otherwise people may realize it somewhere down the road and fairly find it disappointing that this information wasn't disclosed.

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

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

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

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