03.09.07

A Field Trip to the Planetarium: Delegation, Authorization Documents, and Auditing

Posted in identity at 12:50 pm by

There has recently been an interesting blogosphere conversation around Kim’s series of posts on delegation. It started with Kim’s post about a statement attributed to Eve Maler. He focused on the phrase “user absent scenario” that Eve reportedly maintains Cardspace doesn’t support. Kim then goes on through a number of posts to explain the concept of delegation. It’s actually a concept that Eve mentioned as well. I think Kim reacted mostly against the phrase “user absent”, and the conversation was then picked up by others as being confrontational. I’d hate to have my casual conversations over coffee reported to the Internet and scrutinized over a single phrase. So please do not construe this post as picking a side between current identity system brands. I don’t see these concepts being deployed very much at all right now, certainly not to Internet scale. Even in Kim’s post he mentions that, using Cardspace, someone can build a system that can delegate a user’s authority. Such systems are not here yet.

What I’d like to do is expand on Kim’s exposition on delegation. You might even say, embrace and extend those thoughts to capabilities of authorization and audit.

The concepts he explains are, in my experience, right on. This stuff is exciting to old directory services developers. It even drew Pete out of his code for a while. Much of my career has been working on a directory service from the inside — where identity is represented as a flat list of authorization entities on the other end of a connection. Connection based services. They are fine for many purposes and necessary. But they don’t support delegation well. They don’t allow an entity to take a subset of it’s authority and delegate it to service for a specific purpose and time. Nor does it allow much more complicated scenarios, like those that actually happen when I walk into a Starbucks and pay with a credit card.

What we need for many operations is identity data, especially data used for authorization, that is composable — something like a document that allows chunks of data from multiple sources to be combined into a single authorization document. That way the data can pass through multiple entities and be securely transformed and composed, almost like a mini-workflow. Often delegation involves a time-bound subset of the authority of one entity given to another entity. There are probably many ways of doing this, but one way is to call those chunks of data “claims”, and the document an “infocard”. There are even techniques to keep the claims secure and yet properly pseudonymous.

BUT, the authorization data still needs to keep track of all the entities that authorized some portion of each request. It needs to be composable, but separable to individual authorization entities. There are many reasons why we need to keep them separate, but one reason is so that we can audit who did what. In my directory services experience, I’ve seen many other services login to the directory service as a privileged account, say serviceAdmin, and then make requests on behalf of its users. But all the audit logs can record is that serviceAdmin did everything. Imagine a backup service. I want to delegate to the service my authority to back up some of my files for a specific period of time each night. When the backup service reads my financial data at 2am, I want the audit log to indicate that is was the backup service reading my data on my behalf, not that it was me reading the data. Hopefully, I was asleep.

Audit logs can be necessary for a service to prove compliance with various corporate policies, but it can also be of great value to the consumer. When I buy something at a store, I usually use a credit card. I almost always get a document from the store, the relying party, that indicates who I am, what I purchased, how much they agree to charge me, and what they agreed to do for me. It’s an audit record. A document that gives me a record that I delegated a bit of my authority to that store for a specific purpose. It’s called a receipt. Then when I get the financial statement that says how much was debited from my account by that store, I can correspond it with the receipt. These are all documents that give are composed of delegation and audit trails from multiple entities involved in the transaction.

What about the field trip to the planetarium?

These concepts are all illustrated in a this rather simple recent event.

A few weeks ago my daughter brought me a permission form. I had to fill it out before she could go with her class on a field trip to the planetarium. It had a check box for whether I would drive her myself, or delegate that to the bus company with which her school had contracted transportation. It had a place for my name and signature, and what dates this authorization was effective. That document was then transported (via a rather unreliable medium) to my daughters teacher, to the school administration, where it was processed (I assume), and some derivative document was filed with the bus company. It is very important to me that all points of delegated authorization are clear and auditable. If my daughter wanders off after the show, I want the bus service to wait for her. I do not want it recorded that I drove my daughter to the planetarium. Because it wasn’t me. I delegated some of my authority to another service. I want my online transactions to have these same capabilities — only better.

Authorization and audit matter, and need to be composable from multiple entities. Delegation is a key concept.

Permalink