Summary

  • Amoeba's capability was a 128-bit bearer reference: a 48-bit server port, 24-bit object number, 8-bit rights map and 48-bit check field joined naming, permitted operations and validation without a central capability manager.
  • A server that accepted the token established that its fields satisfied the server's verification rule and that the requested operation fell within the rights bits. It did not establish a named holder, approved purpose, completed downstream effect or durable persistence.

The most important fact was in the missing field

A process approached an Amoeba server with a compact bit pattern. The server port directed the request toward a service. The object number selected one object known to that server. The rights bits said which operations the bearer could ask for. The check field let the server detect a forged token or an attempted expansion of authority.

There was no “person” field.

That absence was not an omission waiting for an identity registry. It was part of the mechanism. Amoeba sought a distributed naming-and-protection model in which capabilities could be handled directly by user processes rather than guarded by one central kernel facility. Authority travelled with the reference. A process that possessed a valid, sufficiently privileged capability could present it. The server verified the capability, not a biography.

The design is a useful historical antidote to a recurring operational error: treating every accepted credential as though it answered every authorization question. Amoeba's capability answered a precise question—may the bearer request this operation on this object from this server? It did not answer who the bearer was in organizational terms, why the request was made, whether an approver intended it, or whether a later real-world effect occurred.

Four fields, four bounded jobs

The 1986 paper Using Sparse Capabilities in a Distributed Operating System gives the format exactly. A capability contains a 48-bit server port, a 24-bit object number, an 8-bit rights field and a 48-bit check field. The total is 128 bits.

The server port and object number perform different jobs. The port identifies the service endpoint under Amoeba's RPC model. The object number has meaning inside that service; the 1991 status report compares a file-server object number to an inode number. The kernel can use the port to locate a server, but it passes the rest of the capability to the server. Location and object interpretation therefore remain separated.

The rights byte is not a universal eight-command constitution. It is a bitmap whose meaning comes from the server's object interface. A file object might expose reading, writing or deletion; a process object might expose starting, stopping or inspection. The same field width does not make those operations equivalent. It gives each service a small, explicit surface on which to state bearer authority.

The check field protects that statement. Amoeba let ordinary processes store and copy capabilities, so the token could not rely on an inaccessible kernel tag. The server retained an object secret and used a one-way transformation to verify that the visible object and rights values belonged with the submitted check value. A client could flip a rights bit in memory, but it could not thereby manufacture the corresponding valid check field.

This is why “unforgeable reference” needs careful wording. The historical construction was designed to make fabrication infeasible under its assumptions. That does not certify a 48-bit field against today's attack budgets, protect a token that has been copied from an authorized holder, or encrypt a capability exposed on an unsafe channel. The 1991 report itself notes that cryptography may be needed to prevent accidental disclosure in an insecure environment.

Attenuation was subtraction, not delegation theatre

An owner capability began with all rights bits on. To give another process less authority, the holder could ask the server to restrict it with a mask. The server first validated the original capability, intersected the existing rights with the requested mask and created a new capability for the same object with fewer rights and a derived check field. The programming guide's std_restrict example expresses the core operation plainly: rights &= mask.

The direction matters. The operation can remove authority. It cannot use a bit mask to add authority that the submitted capability did not already carry. If a user changes the visible rights to claim more, the check no longer matches and the server rejects the token.

The papers must also be read without collapsing their design variants. The 1986 sparse-capabilities paper examines several ways to protect rights. One combines a stored random value and rights through a one-way function. Another asks the server to mint a restricted token. A third explores local attenuation with a family of commutative one-way functions. The 1991 status report describes the server-assisted scheme used in its account of Amoeba. These are related experiments, not one indistinguishable algorithm.

That distinction preserves the real authorship boundary as well. Using Sparse Capabilities is by Andrew S. Tanenbaum, Sape J. Mullender and Robbert van Renesse. The Amoeba Distributed Operating System—A Status Report is by Tanenbaum, M. Frans Kaashoek, van Renesse and Henri E. Bal. Amoeba was collective systems work. Tanenbaum is a legitimate human entry point, not a licence to erase the other designers and implementers.

Possession was authority, but not identity

The 1986 paper states that a holder can give another process an exact copy by sending the bit pattern. It also notes that the system need not keep a central record of who possesses which capabilities. Those properties made the mechanism portable and location-transparent. They also define its evidentiary limit.

A successful check says the submitted token is valid for the named object and visible rights under the server's current secret. It does not say whether the presenting process received the token directly from the object creator, inherited it through a directory, received it from another process, or copied it from somewhere it should not have been exposed. It does not bind a human employee, contractual role or legal principal unless another mechanism supplies that binding.

Nor does validity prove purpose. The same write-capable token can be used for routine maintenance, emergency recovery or an unauthorized experiment. Rights constrain which verbs the server will accept; they do not encode the business justification for choosing one of those verbs now.

Revocation has the same bounded shape. In the described model, changing the server's stored random value can invalidate the existing capabilities for an object. That is a powerful object-wide reset. It is not selective knowledge of every copy, retrospective attribution of prior use, or evidence that leaked bit patterns were erased from every process and archive.

The reply stops at the server's semantic edge

Suppose a valid capability permits an operation and the server returns success. The strongest warranted claim is the one defined by that server operation. If the operation modifies a server object, the reply may establish that the server accepted and performed that modification according to its implementation. It does not automatically prove that the change survived a crash, reached every replica, moved a physical actuator, completed an external payment or satisfied an organizational change policy.

Those are separate control surfaces. Persistence belongs to the storage and recovery boundary. A triggered physical or network action belongs to the subsystem that executes and observes it. Human authorization belongs to the organization that sets the mandate. A compact token can unlock one operation without becoming a universal receipt for everything expected afterward.

This is the durable contribution of the Amoeba example. It joins naming and protection with unusual clarity, then stops. The boundary is not a weakness to be hidden. It is what makes the mechanism intelligible.

Sources