Capability ideas have been invented several times. They appear in these contexts:
Cap CPU; (ISA)
Hank Levy’s book recounts the history of hardware implementations of capabilities thru the Intel 432. An important division in this category is between segregated capability storage (Plessey 250) and extra bits in memory that the hardware uses to discriminate between data and caps (System/38 & CHERI). All of the hardware support for capabilities that I have seen presumes some software, unconstrained by cap rules, to complete the system. Currently CHERI tries to preserve important elements of Linux, based upon the more general Capsicum ideas of capability savvy hardware.
Capability Kernel upon conventional CPU
Unix and Linux are not capability systems but those kernels have elements of capability ideas. Most of the systems named here have capability aspects. Keykos, Coyotos and seL4 are such kernels. All of the capability kernels I have seen require at least privileged mode hardware feature so that the kernel can maintain control.
Language (sort of type safety)
You can sense capabilities in Alonzo Church’s work in the 30’s and 40’s. In the last few decades computer language designers have been discovering and adapting ideas from Church’s Lambda calculus, in which I see capabilities. Java’s JVM is a software platform with something close to capability security. It is close enough to convince me that such a platform could support programs in multiple computer languages interacting by capability discipline.
Crypto
Public key technology supports most capability patterns across untrusted networks of computers. Mark Miller pointed out early that knowing a public RSA key was like holding a capability and knowing the corresponding private key was like being the designee of the capability. The public key fails to locate, however. SDSI is an important exploitation of these ideas. OAuth 2.0 is better known but not as flexible, I think. While crypto supports distributed capability designs and capabilities spawn crypto ideas, crypto itself is not a capability system for it fails to limit other causal paths in an extended computation.
trusted network
I propose some very preliminary ideas here. ‘Trusted network’ may sound paradoxical, but a PCIe network may extend only inches.
Matt Rice contrasts (cap kernels with segregated storage) with languages relying on memory safety thus: I propose “capability system” to describe systems that are able to limit the actions of programs in acquiring and transmitting information, to capability means. This is the basis on which I exclude Unix. Crypto systems are likewise excluded.

These various technologies mainly complement each other. They each do well standing alone specializing in solving classes of security problems. I claim just now that the capability kernel solves perhaps the most pressing security problems without boiling the ocean.

Mark Miller asks whether UIs with “authorization via designation” count as another category. Good question.

There are protocols to link CPU or Kernel capability systems over reliable communication links. Where do these fit?

I would like to say that a “complete capability system requires” a place to insert code or behavior that wields capabilities so that patterns such as attenuation are possible. This needs more precision. This category might exclude IBM’s System 38 and its subsequent lineage. IBM seems to have thought that no programmer outside IBM could understand invoking a capability.

The first three plans, CPU, Kernel, Language, each posit a closed system of capabilities. This limitation may usually be transcended by invisible virtual remote capabilities. Some software platforms survive space and time hogs — programs that keep allocating space until there is no more, or never terminate. Just now I do not know of any attempts to make language based systems survive space or time hogs. The E vats provide some protection here that I do not understand.

Some propose that there is a new world here.