This is kind of a long 101-course level take on capabilities, wrapped around this company's product.
The actual technical guts of this approach, the part most HN people care about, most cloud providers have been doing for over a year now: you take (say) an HTTP API call that's enabled by a fully-privileged bearer token, you hide the bearer token from the client inside a proxy, and then you have clients use the proxy instead of the real service, which screens requests.
Then all you're adding here is the classical notion of a "capability", which is to say that you're explicitly and inseparably coupling naming and privileges. In a capability system there is no "github.com" with ambient privileges; there's only "github.com.capabilities.dev/this-set-of-privileges". To know the API endpoint is to know and be limited by the set of things you're allowed to do.
This idea is interesting and important but I think screened access to Github undersells it, or is a half-hearted implementation. In a capabilities system, those capability blobs are the only way to access services. In a K8s system where you're opting in to a specific set of "capabilities" but still have ambient permissions for lots of APIs, you're not really doing capabilities so much as a fancy token system.
This is kind of a long 101-course level take on capabilities, wrapped around this company's product.
The actual technical guts of this approach, the part most HN people care about, most cloud providers have been doing for over a year now: you take (say) an HTTP API call that's enabled by a fully-privileged bearer token, you hide the bearer token from the client inside a proxy, and then you have clients use the proxy instead of the real service, which screens requests.
Then all you're adding here is the classical notion of a "capability", which is to say that you're explicitly and inseparably coupling naming and privileges. In a capability system there is no "github.com" with ambient privileges; there's only "github.com.capabilities.dev/this-set-of-privileges". To know the API endpoint is to know and be limited by the set of things you're allowed to do.
This idea is interesting and important but I think screened access to Github undersells it, or is a half-hearted implementation. In a capabilities system, those capability blobs are the only way to access services. In a K8s system where you're opting in to a specific set of "capabilities" but still have ambient permissions for lots of APIs, you're not really doing capabilities so much as a fancy token system.
[dead]
Re-inventing capabilities, 50 years too late. The CAP Computer was running a full hardware-enforced capability system in 1976:
https://en.wikipedia.org/wiki/CAP_computer