One of the curious things about academics is how the structure of their institutions encourages them to become extremely specialized. The doctoral process and it’s follow-on the tenure process both encourage an extremely depth first drill down into a domain. Each paper they write is required to be tightly entangled in the literature via references and a long reprise of what has come before.

This is a little like a man who has spent his entire legacy to purchase a very expensive peice of equipment, say a high speed drill press. In a variation on the if all you have is a hammer everything looks like a nail when you present a highly trained academic with your problem, say a leaky roof, he starts thinking – “Hm. You know I think we could get my drill press up there on the roof… sure, no problem.”
My life has been much broader and much much more shallow. And when presented with a leaky roof I often find myself thinking; “Hm, I worked in an umbrella factory once – maybe 30 years ago…”

I was reminded of that by reading Tim Orton‘s post of a list of links to systems that allow delegation of rights to other parties.

These papers were a nostalgia trip for me. Back in the 70s at CMU I had some light involvement in the development of a multiprocessor system known as C.mmp. The operating system had a clever way of managing rights. It used something called “capabilities.” Capabilities where a much better but in the end impractical design. Today operating systems use an approach called access control lists – a lousy but practical design.

Access control lists, usually called ACL, protect things by marking objects with a list enumerating who is allowed access. If the question arises “Is Bob allowed to update the payroll data?” the ACL system checks that list to see if Bob’s on the list, if so it allows the change. ACL’s are like the guest list at an exclusive party, each time another guest shows up the doorman checks their ID against the guest list before letting them in. Maintaining the guest lists is a pain, so is the managing the ID cards.

Capabilities allows Bob to delegate the task of updating the payroll to one of his acquaintances.

In a capability system Bob carries around large set of capabilities. Think
of one of those huge key rings that building maintenance
guys carry around. When Bob wants to modify the payroll data he pulls
out the right key/capability and presents it to the system, which then checks
it. If Bob want’s to delegate, he can hand the key to his assistant. Keeping
all these keys under control is a pain.
Real world system work with a hybrid of keys and guest lists. In some situations you present an ID card (for example to withdraw books from the public library) and in other scenarios your provided with a key (for example when you rent a car).

I’m finding it very chew on all that, particularly because there is lots of work going on these days in and about identity systems for the net. It’s an amusing puzzle: is a browser cookie more like a capability or an identity card? … Yes. It depends. Ah, no it’s really something else. More about groups…