Comparing capability systems

[Alan Karp]

I've been asked to write a pros and cons of different types of capability systems.  

The first piece is listing the types.  I have object references, such as endosjs.org, opaque tokens, such as waterken, and certificates, such as zcaps and Macaroons.  Are there other categories?

The next piece is listing the actual pros and cons.  I'd appreciate any input you have.

--------------
Alan Karp

[Pierre Thierry]

Le 05/03/2026 à 17:05, Alan Karp a écrit :

The first piece is listing the types.  I have object references, such as endosjs.org, opaque tokens, such as waterken, and certificates, such as zcaps and Macaroons.  Are there other categories?

Maybe opaque tokens could be divided among swiss numbers and encrypted certificate-like data? In the certificates category, Biscuit should probably be mentioned.

The next piece is listing the actual pros and cons.  I'd appreciate any input you have.

I'd say among the most prominent features of certicates is a dual of pros and cons: they don't need a SPOF/bottleneck, but if you choose them because that property is important to you, it means you can't have up-to-date revocation lists. I think macaroons don't make this possible, but zcaps and Biscuits can be attenuated without communicating with anyone in the delegation chain.

When capabilities are tokens made of bits, an important cons is that you lose the confinement property.

Curiously,
Pierre Thierry
--

pie...@nothos.net
0xD9D50D8A

[Chris Hibbert]

On 3/5/26 8:05 AM, Alan Karp wrote:
>
> The first piece is listing the types.  I have object references, such as

> endosjs.org <http://endosjs.org>, opaque tokens, such as waterken, and

> certificates, such as zcaps and Macaroons.  Are there other categories?

Do hardware solutions, where the reference is an address count as a
different type?

Chris
--
It is easy to turn an aquarium into fish soup, but not so
easy to turn fish soup back into an aquarium.
-- Lech Walesa on reverting to a market economy.

Chris Hibbert
hib...@mydruthers.com
Blog: http://www.pancrit.org
http://mydruthers.com

[Alan Karp]

On Thu, Mar 5, 2026 at 9:10 AM Pierre Thierry <pie...@nothos.net> wrote:

Le 05/03/2026 à 17:05, Alan Karp a écrit :

Maybe opaque tokens could be divided among swiss numbers and encrypted certificate-like data? In the certificates category, Biscuit should probably be mentioned.

The only significant difference between a swiss number like token and an encrypted certificate that the holder can't decrypt seems to me to be where you hold the associated metadata.  

Nice catch on Biscuit.  I've added it to the list.

The next piece is listing the actual pros and cons.  I'd appreciate any input you have.

I'd say among the most prominent features of certicates is a dual of pros and cons: they don't need a SPOF/bottleneck, but if you choose them because that property is important to you, it means you can't have up-to-date revocation lists.

I haven't seen SPOF used to justify certificates.  Offline delegation is the usual reason.

The best justification for opaque tokens is performance because you don't need to validate signatures.  We designed an opaque token system for HPE because they wanted to handle many thousands of requests per second per server.  Each request needed only one hashmap lookup per element in the delegation chain.

Isn't the freshness of the revocation list the same?  For both types, you send a message to the resource saying to stop honoring the delegation.

I think macaroons don't make this possible, but zcaps and Biscuits can be attenuated without communicating with anyone in the delegation chain.

The holder of a Macaroon can create a new one with attenuated permission as with zcaps and Biscuits. 

When capabilities are tokens made of bits, an important cons is that you lose the confinement property.

Why don't you also lose the confinement property with others, such as zcaps?  If I can share a token made of bits with you, I can share a zcap and the corresponding secret key with you.

--------------
Alan Karp