A strawman access control model

This is so simple I'm sure it's been invented already, but I can't be bothered at the moment to track down where. [Ed. Note: It's pretty close to, but not necessarily exactly the same as row-level security and cell-level security in modern databases]

• The world consists of a set of records/objects (I'll call them objects, risking confusion with other definitions).
• Pick a query language by which you can select a subset of this universe.
• With each party that can access the world, associate a number of queries, for example
• A read query. Any query that party makes must return a subset of the results of its read query. If it contains anything else, the entire query is rejected with a simple "access denied" error.
• An add query. Notionally, execute this query after tentatively making the addition(s). If all additions are in the result, the addition commits. Otherwise it fails with a simple "access denied" error.
• A delete query. The records to be deleted must be a subset of the results of the delete query. Otherwise ... you know the drill.

As always, an implementation doesn't actually have to make the queries in question, as long as you can prove it acts exactly as if it did.

Minimal as this is, it may be enough to usefully control access to a personal datastore. For example, I could allow anyone who successfully authenticated as a travel agent add permission to, say, (type=calendar-entry and tags contains travel and tags doesn't contain public). I would grant random people read access to (tags contains public), delete access to nothing and maybe add access to (type=comment and tags contains public).

By default my travel agent's entries would be private unless I did something to make them public. I can blacklist people by reducing their add and read queries, and conversely I can allow privileged access by expanding their queries.

What I'm doing here is basically punting almost all of access control over to the query model of the datastore and to the authentication model that establishes the identity of a party and finds its associated metadata.

A major assumption is that in order to be useful, the query model has to be pretty powerful anyway. In other words, figuring out what objects to grant access to (and what additions/deletions to grant permission for) is no harder than getting useful information out of the datastore in the first place.

Access control models have query models hidden in them one way or another, so why not use what you've already got?