What is OCAP and why should I care?

OCAP refers to Object CAPabilities. Object Capabilities are one of many possible ways to achieve capability-based security. OAuth Bearer Tokens, for example, are an example of an OCAP-style implementation.

In this context, OCAP refers to an adaptation of ActivityPub which utilizes capability tokens.

But why should we care about OCAP? OCAP is a more flexible approach that allows for more efficient federation (considerably reduced cryptography overhead!) as well as conditional endorsement of actions. The latter enables things like forwarding Create activities using tokens that would not normally be authorized to do such things (think of this like sudo, but inside the federation). Tokens can also be used to authorize fetches allowing for non-public federation that works reliably without leaking metadata about threads.

In short, OCAP fixes almost everything that is lacking about ActivityPub’s security, because it defines a rigid, robust and future-proof security model for the fediverse to use.

How does it all fit together?

This work is being done in the LitePub (maybe soon to be called SocialPub) working group. LitePub is to ActivityPub what the WHATWG is to HTML5. The examples I use here don’t necessarily completely line up with what is really in the spec, because they are meant to just be a basic outline of how the scheme works.

So the first thing that we do is extend the AS2 actor description with a new endpoint (capabilityAcquisitionEndpoint) which is used to acquire a new capability object.

Example: Alyssa P. Hacker’s actor object

{ “@context”: “https://social.example/litepub-v1.jsonld", “id”: “https://social.example/~alyssa", “capabilityAcquisitionEndpoint”: “https://social.example/caps/new" […] }

Bob has a server which lives at chatty.example. Bob wants to exchange notes with Alyssa. To do this, Bob’s instance needs to acquire a capability that he uses to federate in the future by POSTing a document to the capabilityAcquisitionEndpoint and signing it with HTTP Signatures:

Example: Bob’s instance acquires the inbox:write and objects:read capabilities

{ “@context”: “https://chatty.example/litepub-v1.jsonld", “id”: “https://chatty.example/caps/request/9b2220dc-0e2e-4c95-9a5a-912b0748c082", “type”: “Request”, “capability”: [“inbox:write”, “objects:read”], “actor”: “https://chatty.example” }

It should be noted here that Bob’s instance itself makes the request, using an instance-specific actor. This is important because capability tokens are scoped to their actor. In this case, the capability token may be invoked by any children actors of the instance, because it’s an instance-wide token. But the instance could request the token strictly on Bob’s behalf by using Bob’s actor and signing the request with Bob’s key.

Alyssa’s instance responds with a capability object:

Example: A capability token

{ “@context”: “https://social.example/litepub-v1.jsonld", “id”: “https://social.example/caps/640b0093-ae9a-4155-b295-a500dd65ee11", “type”: “Capability”, “capability”: [“inbox:write”, “objects:read”], “scope”: “https://chatty.example”, “actor”: “https://social.example” }

There’s a few peculiar things about this object that I’m sure you’ve probably noticed. Lets look at this object together:

• The scope describes the actor which may use the token. Implementations check the scope for validity by merging it against the actor referenced in the message.
• The actor here describes the actor which granted the capability. Usually this is an instance-wide actor, but it may also be any other kind of actor.

In traditional ActivityPub the mechanism through which Bob authenticates and later authorizes federation is left undefined. This is the hole that got filled with signature-based authentication, and is being filled again with OCAP.

But how do we invoke the capability to exchange messages? There’s a couple of ways.

When pushing messages, we can simply reference the capability by including it in the message:

Example: Pushing a note using a capability

{ “@context”: “https://chatty.example/litepub-v1.jsonld", “id”: “https://chatty.example/activities/63ffcdb1-f064-4405-ab0b-ec97b94cfc34", “capability”: “https://social.example/caps/640b0093-ae9a-4155-b295-a500dd65ee11", “type”: “Create”, “object”: { “id”: “https://chatty.example/objects/de18ad80-879c-4ad2-99f7-e1c697c0d68b", “type”: “Note”, “attributedTo”: “https://chatty.example/~bob", “content”: “hey alyssa!”, “to”: [“https://social.example/~alyssa"] }, “to”: [“https://social.example/~alyssa"], “cc”: [], “actor”: “https://chatty.example/~bob" }

Easy enough, right? Well, there’s another way we can do it as well, which is to use the capability as a bearer token (because it is one). This is useful when fetching objects:

Example: Fetching an object with HTTP + capability token

GET /objects/de18ad80-879c-4ad2-99f7-e1c697c0d68b HTTP/1.1 Accept: application/activity+json Authorization: Bearer https://social.example/caps/640b0093-ae9a-4155-b295-a500dd65ee11

HTTP/1.1 200 OK Content-Type: application/activity+json

[…]

Because we have a valid capability token, the server can make decisions on whether or not to disclose the object based on the relationship associated with that token.

This is basically OCAP in a nutshell. It’s simple and easy for implementations to adopt and gives us a framework for extending it in the future to allow for all sorts of things without leakage of cryptographically-signed metadata.

If this sort of stuff interests you, drop by #litepub on freenode!