Comment by black_knight | Hacker News Reader

Comment by black_knight | Hacker News Reader

Parent Full thread

I have designed capability based HTTP APIs before, it took some work but the end result was ergonomic. Of course over the web the capabilities must be secured in some way. I opted for keys to prove that you can perform a given action.

So, “utter” there means make a valid request with a key. On both the client side and the server side the keys and validations were invisible to the business logic, they just carried objects as usual.

You created capabilities by registering a handler for the operation, and got back a token object you could hand out and even send over the api to those who were meant to use them. And the clients got these objects which they could just manipulate and keep around for making API requests.

The cool part was that you could never forget to do an authorisation check. The keys were automatically checked when the request came in. An API request handler would have no privilege itself, it would only call the key-validated handlers created when the capability was minted.

Oh, I'm sure it can be done, and what you're describing sounds quite nice.

All I take issue with is the claim that this is a way to make the unauthorized actions "impossible to utter". The reality is that, at least at some level, you always have to evaluate a request and, based on some cryptography related to user identity, decide if you'll honor it or refuse it. That may be checking a cookie to look up the user and then checking a separate place to see if the user is authorized to perform the action (perhaps with an extra step of finding a role, etc), or it can be checking a "pre-approval" signature obtained at some earlier point as you're describing here, but it's ultimately the same concept, and isn't "implicitly handled" in one case anymore than the other.

I would hate to argue over semantics. But in addition to the keys being checked automatically at run time, the type system ensured that, unless the capability had been revoked, illegal requests would not type-check at compile time. Which I think is pretty close to unutterable.

The keys were there to stop an attacker, the type-checker helps the good guys stay in line.

> the type system ensured that, unless the capability had been revoked, illegal requests would not type-check at compile time

I don't think I can imagine what you mean here. How would my compilation success depend on whether an Admin has given me the right to read or write to a certain path?

First, I am talking about the capability based HTTP APIs I have worked on here. Not some imagined operating system. I can see if I get around to your question in the other sub thread.

But the point is, you would not grant access to a “path” or some such. You gain access to a collection of actions, described by types. It can be simple “get/set property” or more complicated actions, maybe involving capabilities to several things at once.

To mint such an access token the “admin” will have say how the actions are performed, and then pass the token to you. The client code then will have a typed set of actions it can perform using the token.

This does not mean that we compile in the specific rights of each user or anything, it only means that we must ensure a valid flow of rights in order for the whole program to compile. You can get a capability in two ways: you mint a capability for something you already can do (you are the admin and own the data base, say), or you receive it (via an API call, say).

There is definitely a knack to design the system with this kind of flow. But once in place it feels very natural, you get the right to do something just in time for your need to do it. Very much principle of least privilege taken to an extreme.

Reply on news.ycombinator.com