This is just a FYI to reference some of the work that Solid is doing in the field of Interoperability. They have created a recent (16 February 2021) Editor’s Draft on the subject: Solid Application Interoperability
This specification was drafted to address the following: Problems and Goals
It looks on first sight like there might be a lot of interesting stuff in this specification, and added incentive for some cross-community interaction as recently discussed with @aveltens and @rubenverborgh 
I don’t see the relevance. ActivityPub is a protocol where access is determined by:
to, cc, bto, bcc, audience)While a distributed ACL system makes sense for web resources, this kind of permission model is entirely inappropriate for ActivityPub, where the access group is always bounded to audience and the final value of audience is determined from the two factors listed above.
Basically, that kind of permission model is appropriate in a system where resources are pulled, like Solid. In ActivityPub, resources are primarily pushed, which is why the current permission scheme is built around pushing messages around.
Thank you @kaniini for the info, and you are right of course to point out these differences, especially related to the ACL approach (which was mentioned on Solid forum in hopes of @cwebber and Solid core team getting to discuss different approaches).
I was not thinking of the whole spec in its entirety to plug some hole in the AP technology landscape, but maybe some specific concepts or even just vocabulary snippets (but tbh lack expertise atm to really gauge that). Is the auth/authz story of AP-federated apps sufficiently complete / crystalized? Especially in non-microblogging domains and in comms between diverse apps…
Maybe this is indeed not useful, but I thought it warranted a crossref 
Yes, I would say the auth/authz story for ActivityPub is fundamentally complete. We are more in the “hardening” phase. But any advice on hardening from SOLID would not be applicable because the messaging model is basically the opposite of ActivityPub.
There are a number of AP projects, like openEngiadina, that want to delve deeply into Linked Data capabilities. At the risk of saying stupid things by lack of knowledge, when looking at the Interop spec I see concepts that come close, not to auth/authz, but to the de-facto NodeInfo / NodeInfo2 standards. I believe NodeInfo was invented to convey the bare minimum of info about instances, while avoiding the complexity of exchanging the entire federation model in machine-readable way (added to this was the informal convention of providing a FEDERATION.md for devs to figure that out more easily).
In this spec (which tbh seems to be very complex to me) there’s the definition of the Application agent with properties such as interop:applicationName and interop:applicationDescription, and it describes how agents (actors) register applications. In particular there are interop:DataRegistration in such registries, that define a type and the shape of that type using Shape Trees Specification:
Semantic Web Applications interoperate by sharing semantics of terms and constellations of resource-oriented data structures. This specification defines shape trees, a mechanism for declaring and operating over constellations of resource-oriented data structures.
I don’t see how the Application agent’s vocabulary is related to NodeInfo. It seems more related to something like OAuth: it describes a client application, not a server to server application.
A good way of thinking about it is that SOLID is more like ActivityPub C2S on steroids. You could use ActivityPub (well, really you would just use LDN itself, which ActivityPub is conceptually extended from) to federate events for a SOLID application that has participants on different pods.
Maybe I should do a blog about this… but I think that SOLID’s insistence on including Turtle in the specification means it’s probably dead on arrival in the real world. The reason ActivityPub has been successful is because it decisively went all in on JSON-LD.