Thread by @LeaKissner

I realized today that I had never talked publicly about something really important about the design of access control systems: design their semantics to be reverse-indexable.

This is a much spicier take than it sounds like, but there's a good reason. 🧵 [1/]

Right now, access control systems are built so you can show up and say "I want access to object X", the system looks up the access control rules for object X, and then figures out whether you should have access. [2/]

With the exception of a few corner cases, the semantics of access-control system you build should be able to be turned upside down. For this you want a reverse index (which wikipedia calls an "inverted index").

en.wikipedia.org/wiki/Inverted_… [3/]

With a reverse/inverted index, you don't have to look up the access control rules according to the name of the object, you can look up what someone has access to. This is freaking magic because you can answer "what does Lea have access to?" [4/]

If you don't have reverse-indexability, then it's very hard to tell someone who's trying to, say, add someone to a group what's going to actuallyhappen when they do. (They should know!) It may have unexpected results, removing or adding people from access to various data. [5/]

It's also tricky to build a dashboard that tracks things like how many people have access to certain data. You may need to get the numbers by brute force, asking for every person and relevant piece of data "does X have access to Y".

More reasons, but ... Tweet thread... [6/]

Now for why this is a spicy take: many of the grammars that people use to do access control do not have this property. In particular, if you're using a policy language, it's *very* unlikely. If you're using ALLOW X/DENY Y semantics (like firewall rules), you don't. [7/]

You might note that Zanzibar, Google's big authorization system, has a grammar which is reverse-indexable. This isn't an accident. (I designed the grammar around several different goals, including reverse-indexing.) [8/]

research.google/pubs/pub48190/

There are some corner cases where reverse-indexibility isn't a key property, but I'll follow up with that later if people are interested. [9/]