A "capability" is just an object reference, like a pointer in your favorite programming language, except that a capability not only identifies the object it points to, but also confers permission to use the object. So if you receive a capability, you can use it. If you don't have the capability, you can't use it.

Cap'n Proto is a capability-based RPC system in that capabilities are a first-class type. That is, any message can contain capabilities pointing to remote objects, and thus the recipient gains access to those objects upon receipt of the message.

In terms of Sandstorm, an app will be able to say "Hey platform, I have an object here that implements this Cap'n Proto interface 'Foo'. Here's a capability (pointer) to it. The user may redistribute this capability at their discretion." Later on, another app may say "Hey platform, I need a capability that implements interface 'Foo'." Then, the platform presents the user with a UI listing all of their matching capabilities and asking them which one to use.

The brilliant bit here is that when the user makes a choice, the platform then hands that capability to the app, and all of the access control _just works_. No need for an OAuth dance, no need to ask the user "Do you want to permit this?" -- obviously they do, otherwise they wouldn't have made the choice. From the point of view of both apps and the user, the whole interaction is trivial. And, critically, the permissions transferred were only for the specific object the user chose, as opposed to broad permissions for the second app to manipulate the first. No "I need access to your contact list, so that I can display a picker for you to choose which friends to invite", instead it's just "Please use the system picker to choose which friends to invite, and I'll never see anyone you didn't select in the first place."

See also: http://en.wikipedia.org/wiki/Capability-based_security