Cloudflare workers use this in an interesting way as well. The capability is basically a function or an object with data and functions is returned from a call to a remote service. The functions are intercepted with proxy to call other services instead of local code.

The callee basically decides what kind of capabilities it provides to the caller with these functions, anything you're given, you have the right to call without any further auth preconditions. Those capabilities can then be delegated by returning them, wrapped or not, to other callers.

I believe you're referring to this:

https://blog.cloudflare.com/javascript-native-rpc

(Just dropping the link here for anyone else wondering.)

(I'm the author of that blog post, and also the tech lead for Workers and the former founder of Sandstorm.)

Yes, great post and really interesting work! Thank you, I really appreciate the sharing culture at Cloudflare.

Cloudflare workers are lead by the creator of sandstorm, and use CapnProto internally which has a really neat capabilities based RPC mechanism as well.

Great to know! I'm not deep in the space but was reading about their recent impl update and it seems really well done and much of the ideas are quite thought provoking.

I'm not sure I'm sold on nano services, but if their scheduling system ends up being good enough, a lot of the problems behind treating local and remote calls homogeneously could go away.

I'm not either tbh, haven't used cloudflare workers myself, though I like their style (ultra low weight, run at the edge) a lot more than AWS's where you have to worry about cold starts. But for anything at the scale I'm doing it, one box running everything itself is enough.

Mostly just excited about capability security :) & what it can hopefully do to make doing things the right way (least privilege) as painless as possible - especially across program or network boundaries.

What happens if authorization to do something is revoked while your code is holding such a function handle?

I'd assume it throws an exception, like it would for a network error

Yeah, as I was reading the OSO piece, it was obvious that a great many of the problems they are solving exist because of RBAC (Role-Based Access Control). With RBAC, changes to access trigger changes to the principal. For example, when a new employee is hired, there is often a complex and time-consuming administrative process of getting their roles and permissions set up for their position, and when they change positions, teams, or leave the company, access control changes must be propagated based on these events.

With something like Attribute-Based Access Control (ABAC), the authorization system controls access to objects by evaluating rules against the attributes of both subject (the entity requesting access) and object (the entity to be accessed).

This can adapt dynamically determine access based on situational aspects: i.e. in an emergency situation, a subject may be granted access when it would be denied under normal conditions. If you've ever been in a situation when there's a problem in production and the only person who can fix it is unavailable, or can't get access, ABAC can be programmed to allow, temporarily, a backup access path. See e.g. https://csrc.nist.gov/Projects/Attribute-Based-Access-Contro...

Hey cratermoon, Oso CTO here.

I'm probably too close to it, so I'm not following: "a great many of the problems they are solving exist because of RBAC"

Oso supports authorization using any combination of RBAC/ReBAC/ABAC you want.

If anything, I would say that sticking with RBAC is the "easy way" to do it, but you push the complexity of managing it onto your end users (the ones who need to administer it). Whereas building authorization that uses attributes like you describe requires more implementation work, but can make the experience easier for users.

Am I understanding you correctly?

All of the examples given mention roles and users. There's no discussion about the attributes of the subjects and objects as first-class entities.