@lritter
The inverse of an access control list, kind of. With ACLs, users start with no rights and get given rights to do specific things to specific objects. ACLs usually start with some entity that can do everything to everything (root, etc.), which also implies that it can grant access to everything.

Capability systems also start with a root capability that has no limits applied to it, and each layer adds additional limitations. For instance, the root capability might give a bunch of users capabilities that allow them to create files and do anything with those files. If a user wants to allow someone else to do something with those files, they can delegate some or all of that capability to another user — for instance, Alice can delegate "read(myCalendar)" to Bob. That but in the parentheses doesn't just have to be the name of an object, though — it's a computational expression. If Alice runs a chat room, she can delegate "edit(messagesYouSent)" to Bob instead.

This is useful for a couple of reasons — first, you don't need to have a central trusted system that knows all of the ACLs. If you're building decentralized/local-first/offline systems, you don't need to check in with a central server to find out if someone can do a thing. There are various cryptographic strategies to make these verifiable.

Second, it allows what might otherwise be relatively complex business logic to be stated declaratively inside the security framework, rather than procedurally in the application code, which makes it easier for humans to understand — just like it's easier for a human to understand a description of the possible states of a system and the transitions between states that are allowed than it is for them to derive that description from a procedure that implements that state machine.

Finally, big ACL systems can get pretty unwieldy. There is often a lot of work required going through the ACLs of various objects, checking to see that they are all the same without exceptions, etc. Of course, you can automate some of this, but then you need to have a simpler way of expressing the same thing — in which case you could just use that simpler thing instead.

The downside of capability systems is a) that because they can express a lot more, they can also become unwieldy, b) that because they're usually expressed computationally, they may expect more of the user, and c) people are used to ACLs, so education is required. This in particular is why I'm interested in systems that already use them.