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.

▲

uncommoncense an hour ago | parent [-]

Right, but where do you get the proof to begin with? Using your OS example, it seems like the OS would need to precompute all of the possible accesses for the file picker? In this case, the OS is an authorization system.

Do you mean that the directory should not be responsible for making this decision and there should be a central authorization authority?

▲

black_knight 41 minutes ago | parent [-]

There a sort of “might makes right” principle here. If you can do it, you can mint a capability for it, which means you will perform the action when someone with that capability requests it.

A central authority is not a requirement. What is required is some way making sure capabilities are unforgeable.

This can be a central authority, which then has a completely mechanical task of registering capabilities and their ownership. But it can also be ensured “cryptographically” with a key.

The OS already has a capability system called “file descriptors”. Which works quite well, within its limited scope. This could be expanded out to more areas.

	▲	simiones 33 minutes ago \| parent [-]
		The question is - how do you get the ability to write to pathA and to pathB but not to pathC, while another user gets the ability to write to pathA and pathC but not to pathB? Do you get a huge list of capability keys when you log into the system, one for each path? Do you ask a service for a capability when you want to perform the action?