---
robots: noindex, nofollow
---

# Musings: Object Capabilities

(I posted this in the gordian channel, could become an article)

Object capabilities (ocaps) are a powerful design pattern for authorization that doesn’t require identity authentication, sometimes called "bearer capabilities." Most ocaps leverage hash-based techniques, such as the HMACs used in macaroons, allowing delegation and attenuation of access rights without tying access to a specific user or identity.

A particularly interesting use of single-use bearer tokens appears in certain Bitcoin Lightning Network implementations, where ocaps are bound to payments. For example, a user could purchase 10 cryptographic tokens, each granting access to a single article. These tokens can be freely transferred or given away without revealing the buyer's identity or requiring any account-based authentication. This makes them ideal for preserving privacy while maintaining controlled access, as service providers do not need to track or link usage to individuals.

Emerging cryptographic capabilities leveraging Schnorr signatures and FROST (Flexible Round-Optimized Schnorr Thresholding) introduce new possibilities for ocaps. In particular, adapter signatures enable conditional delegation and atomic capability transfers, making it possible to enforce access rights without disclosing unnecessary information. This allows for sophisticated privacy-preserving models, such as pay-to-reveal mechanisms or collaborative multi-party delegation, without relying on centralized trust or identity verification.

---Capabilities, as a design pattern, broadly refer to unforgeable tokens of authority that grant specific rights to their holders. This definition encompasses a wide range of mechanisms, including both object capabilities (ocaps) and other capability-based approaches that may not strictly adhere to ocap principles. While ocaps emphasize delegation and attenuation—allowing fine-grained control over how rights are transferred and constrained—not all capability systems require these features.

Some systems implement **capabilities without object capabilities**, meaning they use bearer tokens or cryptographic constructs to grant access but do not necessarily follow the ocap model of encapsulating authority within objects. For example, single-use cryptographic tokens, as seen in certain Lightning Network implementations, are capability-based but do not inherently involve object references, delegation chains, or direct invocation-based access control.

This distinction often comes down to **how authority is structured and transferred**. While ocaps enforce security by ensuring that authority flows only through explicit references, other capability models might focus purely on **who holds a token** rather than how it was obtained or whether it can be delegated. Both approaches offer strong security and privacy advantages over identity-based access control, but the presence or absence of structured delegation and attenuation mechanisms is what some consider the defining difference between a general capability system and a true ocap system.