A capability is a protected reference. It is a reference in that it designates an object; it is protected in that in cannot be forged. A capability both designates the object it refers to and carries the authority to manipulate it.
By binding designation and ?authorization together, capabilities simplify delegation. Imagine that program instance A wants to tell program B to use a particular file to store some data. Further imagine that A and B are running in different ?trust domains (e.g., with different UIDs). If A sends B just the name of the file, B needs to first ensure that he does not accidentally enable A to access the file on his own authority. That is, B wants to protect against A hijacking his authority. (This problem is refused to the confused deputy problem.) Also, since A likely sent a string to identify the file to B, the identifier lacks a naming context and therefore may resolve to a different object than A intended. By ensuring that designation and ?authorization are always bound together, these problems are avoided.
If you found the above example a little too abstract, then consider the example found on the wikipedia page. Suppose a trusted server runs a compilation process, bills clients for using the service, and stores billing information in the "bills.txt" file. The compilation server needs clients to provide the name of the input and output files to compile the program. Suppose a client calls the compilation server and specifies the output file as the "billing.txt" file. The server compiles the program, and then overwrites the billing information. Now the server does not know who to bill for the use of its services.
Capability-based system architectures strive to meet the principle of least privilege (Wikipedia, principle of least privilege).
A capability mechanism is typically implemented in software by the operating system kernel (typically a microkernel). The computing cost (as compared to a hardware implementation) is neglectable.
UNIX
UNIX file descriptors can be viewed as capabilities. They do not survive reboot, that is, they are not persistent. To work around this, ?ACLs are used to recover authority.
GNU/Hurd
In the GNU/Hurd system, a capability is represented by a Mach port. As in UNIX (see above), they are not persistent.
IRC, freenode, #hurd, 2013-07-01
<nlightnfotis> I have read plenty of documents, and wrapped my head around most Hurd concepts, but I still have not understood well what capabilities are.
<youpi> Mmm, which capabilities?
<youpi> AIUI, the Hurd doesn't really have a notion of capabilites, just a notion of owning a port right
<nlightnfotis> From what I have understood (from the critique) they reference ports so they objects can be referenced via them
<youpi> (which provides processes a way for doing things)
<youpi> ok, so we are talking about the same thing, I guess
<nlightnfotis> ahh, that's cool. I thought there was more to the story that I couldn't understand