About

What is capability security?

Capability security is a security model to manage how objects perform actions on other objects. An object (i.e. subject) must present a capability to their target object (i.e. resource) with their request. This capability is all the proof that is needed in order for the request to proceed.

A capability is made up of two things: the authority to perform the action and the designation or the complete, unambiguous name of what it is acting on. While not strictly necessary in the model, Hessra capabilities also include the operation (e.g. read/write) for the action.

What is Hessra?

Hessra is an implementation of the capability security model meant for distributed systems. Our capability and identity tokens are built on biscuits. Once minted and fully designated, the capability tokens fail closed.

We provide a 100% open source, open core of our primitives and our core capability engine under the Apache-2.0 license. You can take our open core and use it to implement capability security into anything you want like a webapp, microservice fleet, IoT, or AI Agents.

We can also deploy and manage a root authority for you and handle key management, token issuance, a policy management API, and root-level governance and revocation.

For larger teams or enterprises, we can provide a full governance layer with policy aggregation, complete audit trails, and fine-grained revocation. Everything needed to make the distributed, compositional capability security model legible at organizational scale.

How does it differ from OAuth?

If you squint, OAuth access tokens kind of look like capabilities because subjects get issued them and they are used with their requests to access things. Missing from the protocol though is a critical piece: designation.

In OAuth systems, who is responsible for complete naming of a resource is ambiguous. This often leads to incomplete naming forcing any verifier of the access token to try and guess which leads to confused deputy problems and broken access control.

Conceivably, you could implement a capability security model using OAuth, but the protocol and ecosystem give no guidance on designation and every implementation ends up solving it differently or not at all. Most feel the pain of uncoupled designations and try to resolve it by stuffing scopes with more information than was intended to be there.

How does it differ from SpiceDB?

SpiceDB on the other hand is a relationship-based policy graph. This pretty much is an object policy graph in capability security. SpiceDB and other centralized policy engines are at odds with actually implementing a capability security model though. Because they are centralized, they lend themselves to being checked at the end of a request which is an access control list (ACL) pattern, not a capability security one.

SpiceDB could be consulted at the start of the request to issue a capability for it, but it has the rough edge of expecting to be the source of truth for the entire object graph, which will cause some friction with designation. The SpiceDB will need to be updated with complete designations in order to make the correct decision, and if anything in the object graph changes, it needs to be propagated to the DB.

The result is that SpiceDB requires the whole system to be described in one place — the opposite of how capability security composes.

Team