First of all, this necessitates a certain data model, where instead of a "UploadFile(file, destPath)" operation, I have to have a "destPath.UploadFile(file)" operation. This would be ok for this case, but not all operations can be expressed in this simple parent -> child relationship.

Furthermore, even here, this doesn't cover another case: what if I am allowed to add files to destPath, but I'm not allowed to modify a specific file? This API still has to fail if `destPath/file.Name` already exists and I'm not allowed to modify it (or it at least has to do something different than when `destPath/file.Name` doesn't already exist).

And even if we accept that we can only ever write things in this way, this still leaves the problem of terminology intact. Depending on the technology, it's simply not true that I can't "utter this phrase" if I don't have the capability. For example, if this is an HTTP API, then I can always do a `POST /dest-path/upload-file` with the file I want, regardless of whether I have the authorization to access that or not. Sure, if it's a HATEOAS-style API, the `GET /dest-path` might not return a link to `./upload-file` at all, but that doesn't mean that I can't utter that sentence - i.e. issue that HTTP request.

▲

black_knight an hour ago | parent [-]

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.

▲

simiones 40 minutes ago | parent [-]

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.

	▲	black_knight 28 minutes ago \| parent [-]
		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.