WAC vs. Object capabilities

Solid Specification
1

(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:

  1. “sufficiently unguessable” ocap URIs (ocap literature: “sturdyRefs”)
  2. ocap certificates (eg zcap-ld)
  3. live references (requires CapTP, which I am working on)
  4. and ok also technically ocap powered storage (datashards)

  1. and 4) are the easiest tie-ins to present infrastructure, but…

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

  3. 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?

3 Likes
2

The authn direction of solid is to infer identity by possession of a DPoP token. This is obviously not the same thing (you cannot delegate it) but I found this funny.

I am worried it could be a little bumpy with the apps. Suppose that you have 100 friends that give you limited read access to their photos. You need to store 100 proofs of capability, but for each app. How do you synchronize it? If you have a 101st friend and get a new capability, how do you make sure that all your apps receive that capability?

2 Likes
3

And my usual question when it comes to signing data: if Alice delegates a capability to Bob, how do you make sure that Bob cannot prove to the public that Alice gave him access to a specific resource?

4

Thanks, I have much to read abd learn about the various mechanisms :slight_smile:

PS. I found this interesting article: Capability myths demolished (did not read original paper, which got mixed review).

5

I have voiced my reserve with regards to signatures more clearly here:

6

I thought the had some discussion of capability based access here but can’t find it immediately.

It was advocated two or more years ago by someone from the SAFE Network community for that project, and ultimately adopted.

I think the similarities in the goals and applications of Solid and SAFE mean that switch is significant in the context of Solid. It suggests that capability based access should be a consideration for Solid if it is not too late. I don’t follow the Solid panels, so maybe there has been discussion of it there.

Having seen how much benefit it is bringing to SAFE in terms of control and extra functionality for users over data sharing I’m convinced it is a much better way of doing things. I understand there has been a long debate over this and I don’t know the full history or details so can’t really argue the case. I’ve just been very impressed at what I’ve read about it on the SAFE forum, and how it has been realised in the UI (there are some detailed UX mock ups showing how this can work, and the features it offers, which should be of interest to designers of Solid).

I haven’t tried to use Solid web access control much myself. I always thought it was fairly neat, easy to understand and could work well, but watching people struggle with both understanding and building with it, WAC seems to need more thought, so maybe there is time to review this before it gets set in stone.

1 Like
7

Very interesting @happybeing. I’ve come upon a couple pro’s and con’s earlier today:

Pros:

  • Efficiency of processing
  • Manageability at (web-)scale and in trustless environments
  • Possibility for very fine-grained authz

Cons:

  • Accountability
  • Revocation is harder

I also read something about best-of-both-worlds solutions being possible, but I don’t have any info on that. And in Capability Myths Demolished there is this comparison table:

Capability Myths Demolished

1 Like
8

As mentioned, I’m not an expert on the detail but surprised to see those cons (accountability and revocation) because we went into it pretty thoroughly on the SAFE forum and downsides like those would have been contentious. It may be due to evolution/improvement or differences between implementations, I’m not sure, but I would love anyone with specific concerns to voice them on the SAFE forum (see RFC link below) and see what the community and more importantly the team who have been designing this have to say.

I know they were unable to make use of what I think was the standard implementation (using “macaroons” - BTW there’s a very good video presentation about this from a few years ago), but have a proposal to deliever equivalent functionality (in this RFC). I think they started a proof of concept which went well, and so have been designing the UI on this basis. They weren’t able to use exactly the same scheme as “macaroons” because that assumes a server based system, but have a verified a scheme which works on a decentralised network (possibly by using BLS key signing).

9

Was it directed to me? If so, I have opened a thread: https://safenetforum.org/t/question-about-capabilities/31816 ^^

10

No, it was directed to the community. I’m glad you took it up though and will follow the discussion.

11

No expert either, and these cons may not apply. I saw them mentioned in a comparison between ACL’s vs. Capability lists. Part of a Udemy course.

1 Like
12

I hope we can get @codenamedmitri to comment…

13

I’d like to post a longer reply when I have more time. But for the moment - I’m involved in both the WAC and the zCap-LD spec (and implementations), and my goal is to make the two complementary / inter-operable.

3 Likes