I've always loved the Guys and Dolls song in which a bunch of guys sing a catchy round about picking their favorite nag at the track. They're telling each other why they've made their pick. It goes like this:
"I got the horse right here
The name is Paul Revere
And here's a guy that says that the weather's clear
Can do, can do, this guy says the horse can do"
...
"I'm pickin' Valentine, 'cause on the morning line
A guy has got him figured at five to nine
...
I know it's Valentine, the morning work looks fine
Besides the jockey's brother's a friend of mine "
...
"And just a minute, boys.
I've got the feed box noise
It says the great-grandfather was Equipoise "
What does this have to do with computers? It provides an easy to understand example of how we make decisions. The gamblers are describing where they got their information and what categories of information matter to them. They rely on a favorite racing form, friends of friends, and gossip from the staff. In the brave new world of dynamic access control, we want to do the same thing to reach an automated decision about what data you can see. Instead of racing forms, we have "trusted sources" or "authoritative data" -- repositories we believe have reliable information. And, instead of the weather, lineage, and distance, we're looking for other categories of facts that consistently help us to reach our decisions.
I've recently done a project in which we attempted to define how many things you really need to know about a system user to decide whether or not s/he can have access to particular government work-related information. The idea was to see if there was an universal core of attributes that most system access rules are seeking. In other words, does the decision about what you can see in the human resources system rely on the most of the same categories of information about you as the decision about what you can see in a criminal case file or a person's tax filing. Our answer is "yes," if you create the right sort of categories. And, much to our surprise, our core list is only thirteen attributes.
What's the right sort of category? Other proposals have made each fact its own category. For example, imagine an attribute which indicates whether someone is a law enforcement officer and a different one for whether someone is a lawyer. Organized that way, you would need thousands (millions?) of attribute categories. But, if you say the attribute is "job description" then you can include officer, attorney, and a million other jobs in one attribute category.
Having a small number of needed attribute categories has a tremendous advantage. It means the software can be less complex, handling a smaller number of variables. It means the processing time should be faster. In this design, each system needs to know only the values it cares about. For example, if the access rules for a system only permit government auditors and law enforcement officers to view the data, the particular system doesn't need to know that a person can be a doctor or a dog catcher. It only looks to see if the person seeking access matches (or has an equivalent to) "government auditor" or "law enforcement officer" in his "job description" attribute.
We think the 13 user attributes are:
Employer Name
Employer Subgroup (as many hierarchical levels as needed)
Employer Type (e.g., federal government, private hospital)
Employment Type (e.g., permanent, temporary assignment, contractor)
Job Designation
Location (physical and virtual)
Location Type (permanent, temporary)
Special authorities/licenses (granted by others)
Management Level
Direct Reports
Rating/Reviewing Official
Skill (ability, irrespective of outside grants)
Skill Level
So far, we haven't come across a data access rule we couldn't parse into one of these attributes. If you do, please tell me.
"I got the horse right here
The name is Paul Revere
And here's a guy that says that the weather's clear
Can do, can do, this guy says the horse can do"
...
"I'm pickin' Valentine, 'cause on the morning line
A guy has got him figured at five to nine
...
I know it's Valentine, the morning work looks fine
Besides the jockey's brother's a friend of mine "
...
"And just a minute, boys.
I've got the feed box noise
It says the great-grandfather was Equipoise "
What does this have to do with computers? It provides an easy to understand example of how we make decisions. The gamblers are describing where they got their information and what categories of information matter to them. They rely on a favorite racing form, friends of friends, and gossip from the staff. In the brave new world of dynamic access control, we want to do the same thing to reach an automated decision about what data you can see. Instead of racing forms, we have "trusted sources" or "authoritative data" -- repositories we believe have reliable information. And, instead of the weather, lineage, and distance, we're looking for other categories of facts that consistently help us to reach our decisions.
I've recently done a project in which we attempted to define how many things you really need to know about a system user to decide whether or not s/he can have access to particular government work-related information. The idea was to see if there was an universal core of attributes that most system access rules are seeking. In other words, does the decision about what you can see in the human resources system rely on the most of the same categories of information about you as the decision about what you can see in a criminal case file or a person's tax filing. Our answer is "yes," if you create the right sort of categories. And, much to our surprise, our core list is only thirteen attributes.
What's the right sort of category? Other proposals have made each fact its own category. For example, imagine an attribute which indicates whether someone is a law enforcement officer and a different one for whether someone is a lawyer. Organized that way, you would need thousands (millions?) of attribute categories. But, if you say the attribute is "job description" then you can include officer, attorney, and a million other jobs in one attribute category.
Having a small number of needed attribute categories has a tremendous advantage. It means the software can be less complex, handling a smaller number of variables. It means the processing time should be faster. In this design, each system needs to know only the values it cares about. For example, if the access rules for a system only permit government auditors and law enforcement officers to view the data, the particular system doesn't need to know that a person can be a doctor or a dog catcher. It only looks to see if the person seeking access matches (or has an equivalent to) "government auditor" or "law enforcement officer" in his "job description" attribute.
We think the 13 user attributes are:
Employer Name
Employer Subgroup (as many hierarchical levels as needed)
Employer Type (e.g., federal government, private hospital)
Employment Type (e.g., permanent, temporary assignment, contractor)
Job Designation
Location (physical and virtual)
Location Type (permanent, temporary)
Special authorities/licenses (granted by others)
Management Level
Direct Reports
Rating/Reviewing Official
Skill (ability, irrespective of outside grants)
Skill Level
So far, we haven't come across a data access rule we couldn't parse into one of these attributes. If you do, please tell me.