(Disclaimer: I’m no expert at this, but want to get more insights and overview. This is a bit of a FYI and asking of opinions).
I am interested in starting some Fediverse (ActivityPub) projects, and using more linked data there, maybe combining with Solid. After the ActivityPub grassroots growth based on the initial spec (with lotsa holes in it, for e.g. auth/authz), there is much activity to converge on a standardization track again.
One interesting part of it is that Christopher Lemmer Webber (one of the co-authors of AP) is looking at stronger user security mechanisms - which he also wants to apply to his own Spritely, a distributed social game / virtual world. Particularly interesting is that he is looking at an object-capability model (ocap) for authorization.
I knew about Authorization Capabilities for Linked Data (zcap-ld), so I asked him about the role of this draft in relation to the fediverse.
Solid, I believe, is mostly on an ACL track with Web Access Control, right? The zcap-ld draft spec compares ACL vs. Capabilities as follows:
Fundamentally, Access Control Lists are about authority by identity whereas Object Capabilities are about authority by possession .
It continues with providing the example of a Car (the object), which in the case of ACL must either be an identity provider or have remote access to one where all people allowed to drive are pre-registered. In the case of ocap the comparison is the familiar concept of Cars having keys that you just pass around to people you allow to drive.
This was Christopher’s answer on the role he sees for ocap in the fediverse:
zcap-ld is one way to implement ocaps. Is it the right one for the fediverse?
There are really three viable paths for a fully rich federated social network:
- “sufficiently unguessable” ocap URIs (ocap literature: “sturdyRefs”)
- ocap certificates (eg zcap-ld)
- live references (requires CapTP, which I am working on)
- and ok also technically ocap powered storage (datashards)
and 4) are the easiest tie-ins to present infrastructure, but…
is going to be desirable if you have a lot of, er, “fast and furious short lived ocaps”, as a virtual world would need. That’s probably not necessary or within the scopes of most others right now.
is nice, and I’m a big enthusiast of zcap-ld, but it’s kind of a jump in tooling vs the amount of payoff available for most implementors right now (whereas 3 is a big jump in payof while also being an increase in tooling)
I’m not really answering your question clearly, so basically: I think bearcaps + datashards (or something like either) for networked ocaps and storage are the fastest path to global fediverse adoption of ocaps.
(But for the virtual world stuff I’m working on, we’ll need CapTP too… but I’m not expecting most fediverse developers to take interest in that yet.)
I am wondering if Solid has considered object capabilities, or compatibility thereof, and any other considerations with this approach?