Comment by simiones
2 days ago
> If the subject can utter the action, then it can perform it.
This sounds like another layer of weird terminology that doesn't mean anything for someone who is not familiar with whatever capability system you're thinking of.
Say I am a user who can see a particular directory on a shared setup. I try to upload a file in this directory, using the same method that worked on another directory. The question of AuthZ is: will I be allowed to do it or not? In the plain sense of the words, I can absolutely "utter the action", I have all of the "verbs" (upload) and "nouns" (the file, the destination path). Still, I should not be allowed to perform the action if I was only given read-only access here.
Now sure, you can say that "upload to dirA" is a different verb than "upload to dirB". But this is just confusing terminology, it doesn't enlighten anything.
You seem to understand it just fine.
Your accessor, dirB, should not contain the “upload files” verb, while your dirA accessor (noun) should.
My favorite example is the home directory and the file picker. Why should a program have access to all your files by default then politely ask you which file it should read/write to? It would make more sense if the file picker was something the operating system ran when a program wants to edit a file, and what came back to the program after you selected was the accessor for that file (with read and/or write verbs).
So the program only have access to those files you have it access to. It cannot even ask the question to open another file, because it only has opaque accessors to those files it has been given.
What you're describing is essentially what the authorization system would need to do in order to answer the question "can this subject perform this action on this object?". If you're suggesting that the program should receive a list a priori, then there are potential scale issues since that list would need to be exhaustive of both nouns and verbs, which can be a large set.
The point is to flip the burden of proof.
Instead of an authorisation system trying to find a reason to give you permission, you have to carry the proof in the form of a “verb”. Which you use when you perform the action.
3 replies →
I used to use the example of Dropbox’s chooser API to illustrate this: https://www.dropbox.com/developers/chooser
If you use this API (via a simple widget library) then the user simply picks a file in their dropbox and the app gets access to that one file. Vs OAuth where you grant the app broad access to the whole dropbox (or maybe some sub-folder).
What you're describing is the difference between Fine Grained Authorization (FGA) and traditional Role-based Access Control (RBAC). This article covers the difference: https://www.osohq.com/learn/what-is-fine-grained-authorizati... (disclaimer: I used to work there but continue to be a fan of their documentation).
1 reply →
You are describing the concept of XDG Desktop Portals [1] on Linux.
1. https://wiki.archlinux.org/title/XDG_Desktop_Portal
Indeed, that strikes me as a fine example of capability inspired design. The mechanism used is passing file descriptors, and for some reason file descriptors is the most "capability based" part of the Linux kernel.
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.
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.
4 replies →