I promised yesterday that I'd talk a little more about our discussion on delegation. I've since had a profitable discussion with Devlin and Bryant as well.

The problem with delegation is that it requires something that has eluded organizations since computer security first became an issue: how do you build good authorization models? Most applications are built without much prior thought to the authorization model and then it gets slapped on afterwards. For organizations, it's even worse. The business has fuzzy ideas about authorizations and they change them all the time. "Oh, we're spending too much money on catering; from now on VP's have to sign off on all catering requests, in triplicate."

To see why an authorization model is needed for delegation, consider this scenario. I work at BYU and BYU has, in the name of efficiency, stopped giving out paper paystubs. It's all online. Also supposed my wife handles the family budget and needs access to the paystub. I always forget to print them out (and besides having everyone print them on expensive laser printers instead of distributing the paper in the first place is lame). I want to authorize my wife to have access to the paystub. I can't. There's no way to delegate my authority to see my paystub.

Consequently, I break BYU policy and give my wife my NetID and password so she can impersonate me and see the paystub (at least in this scenario). Of course, because she's impersonating me, she has all my rights and can also change student grades, update the 401K, and send a nasty note from me to the University president. Now, she wouldn't do any of those things, but BYU doesn't care that she wouldn't, they care that she might. And so, there's strict policy against sharing NetIDs and passwords, like there is in most organizations.

BYU has set up a situation where their practice (electronic paystubs without a delegation system) sets up situations where people routinely ignore their policy (don't share NetIDs). Of course, BYU isn't alone in this folly. Every organization on the planet has these problems and the increased mechanization of formerly people-based processes is only going to exacerbate them.

Solving this problem for this one instance of delegation isn't all that hard: add a way for me to select any other NetID to also see my paystub. Since almost anyone can get a NetID of their own at BYU (universities are at an advantage here), my wife could get her own NetID and I could select her to see my paystub and the problem is solved.

Solving the problem more globally is much more difficult, nigh unto impossible. After all, I want to delegate all kinds of things: my son to use my bookstore discount, my TA to keep grades, my colleague to update my course calendar when he substitutes for me, my assistant to update my appointment calendar, etc. The list is endless.

You could imagine a bunch of smart people sitting down and coming up with lists of roles, lists of resources, lists of actions on resources, lists of permitted delegations, and then building a big edge-colored, acyclic graph that represents all of this that the various systems on campus could query to get "the answer." Of maybe you couldn't imagine that. I can't. I especially can't imagine them meeting day after day to update the graph as things change as they inevitably do in a community of 50,000 individuals.

This is the same problem that the Semantic Web faces: endless debates about ontologies. Dave Weinberger, working on his Everything is Miscellaneous book, would probably agree that such a task is hopeless. We're likely to end up right back where we are now: building one off delegation solutions

Devlin, Bryant, and I were wondering if there are ways to use folksonomies to solve this problem. Is there an analog for authorization that would work in many cases and allow common usage to define the cowpaths? You'd still need to identify resources and actions that need explicit authorization to meet legal and risk requirements, but is that most things or a small subset? I'm not sure.