Thank you for joining in!

However, they do introduce a cryptographic dependency — since they explicitly include the security problems typical of bearer tokens in their threat model — and it sounds like you jay be trying to reduce specifically signature verification load?

I'm more concerned with the complexity of signature verification, rather than the load / performance overhead. Keys are harder to manage than tokens, and algorithm changes are extremely non-trivial. HTTP signatures are particularly messy since you have to parse and serialize HTTP in a consistent way across all implementations. Tokens are much simpler, and therefore easier to get right.

capabilities are very much aimed at distributed (including federated) use cases!

So for federated use cases, my concern is this: How do we handle the case where two users on the same system are granted different capabilities by a remote system? Should the local system try to parse the capabilities and assign access based on that? Should we segment local data based on who's viewing it, potentially having multiple copies of remote content with different associated keys? Something else? What access should we give to other users interacting with content that was received with multiple different capabilities?

However, I'd love to hear more about your use case, but from the original post in this thread it sounds like they could be a really nice fit as capability systems are essentially an extension to the actor model.

I see an additional problem with AP specifically. In AP, URLs are used as identifiers for all kinds of content. The examples I've seen showed activity / object IDs including an embedded capability, which means that the same object can have multiple canonical IDs. How should local systems handle that? How should remote systems know that two remote actors are referring to the same object, when the referenced IDs are different?

Thanks for the questions! The good news is that for bits about expressivity, capabilities are extremely expressive and you can model most auth systems in them. Also I have no skin in the game here; I just want to be helpful and be a resident capabilities expert here to have my brain picked.

I'm more concerned with the complexity of signature verification

I'm not sure that it's much more complex, but I historically I haven't used HTTP signatures but rather signed RPC tokens with HTTP as a transport, just like JWT (in fact UCAN started as JWT but we now use a canonicalised format for compression reasons)

How do we handle the case where two users on the same system are granted different capabilities by a remote system?

This is arguably one of the core things that capabilities are meant to solve. Core to their design is that all granular agents should have different IDs, and you can route their capabilities arbitrarily and unambiguously because you're using asymmetric crypto. Anyone looking at the data should have their own permissions. There are definitely ways of doing granular access without storing multiple copies of the same data using links.

I'm unclear how a bearer token improve things help here, though

the same object can have multiple canonical IDs

Then they're not canonical in the original sense, but I'd assume that in this case referencing by multiple IDs is the same as making calls to different proxies on the same underlying data. There's a long history for doing that with object capabilities.

If you want something less federated and more, say, local first with no single source of truth, then you probably do want a canonical ID. Local-first capabilities, we tend to use public keys as an identifier for the data over time, and to trace the flow of authority wherever it lives. You don't have to do this, you could add a naming layer on top that hides the name proxying information for API convenience, but it's probably less of a win then you'd see on the surface.

How should remote systems know that two remote actors are referring to the same object, when the referenced IDs are different?

You have complete provenance information, so they treat it the same as proxying. If you want to do it statically you'd have an equivalence class (basically a table). I really don't think this would be a problem.

Thanks for the questions! The good news is that for bits about expressivity, capabilities are extremely expressive and you can model most auth systems in them

That's good to know! Would probably be easier than the complex heuristic stuff currently used to figure out access rights in AP.

I'm not sure that it's much more complex, but I historically I haven't used HTTP signatures but rather signed RPC tokens with HTTP as a transport, just like JWT (in fact UCAN started as JWT but we now use a canonicalised format for compression reasons)

Those are both much simpler than HTTP Signatures. I would be completely comfortable using JWTs for federation, as they solve many of the same problems and come with the bonus of good library support.

This is arguably one of the core things that capabilities are meant to solve. Core to their design is that all granular agents should have different IDs, and you can route their capabilities arbitrarily and unambiguously because you're using asymmetric crypto. Anyone looking at the data should have their own permissions. There are definitely ways of doing granular access without storing multiple copies of the same data using links.

What happens if users A and B on instance X both get different permissions from object M on instance Y, and then both make replies N and O (respectively). If A views M, how should B know to show both N and O as replies?

Then they're not canonical in the original sense, but I'd assume that in this case referencing by multiple IDs is the same as making calls to different proxies on the same underlying data. There's a long history for doing that with object capabilities.
If you want something less federated and more, say, local first with no single source of truth, then you probably do want a canonical ID. Local-first capabilities, we tend to use public keys as an identifier for the data over time, and to trace the flow of authority wherever it lives. You don't have to do this, you could add a naming layer on top that hides the name proxying information for API convenience, but it's probably less of a win then you'd see on the surface.
You have complete provenance information, so they treat it the same as proxying. If you want to do it statically you'd have an equivalence class (basically a table). I really don't think this would be a problem.

I don't quite understand this, sorry.

is there a canonical ID, then? Basically, I'm wondering how a system with multiple users should know that two references resolve to the same underlying data.