Two issues with the policy access protocol idea

A couple of weeks ago I raised the idea of crafting a policy access protocol so that applications and services would be able to standardize the way they create, modify and use policies as part of an implementation of policy-based management. This generated some discussion which quickly resolved to two major issues.

The first issue, raised by a number of people, was that the term “Policy Access Protocol” was going to cause confusion.

As I said in that newsletter, the Organization for the Advancement of Structured Information Standards has created XACML, the Extensible Access Control Markup Language. I said XACML was a good starting point, but policy management includes more than just access control. As my correspondents pointed out, saying that “policy access” was needed because “access control” wasn’t enough was both confusing and placed an emphasis on “access” that made it seem more important than “policy.”

My protocol suggestion also had an unfortunate acronym, as some mentioned. So I’m thinking the better choice would be Policy Management Protocol (PMP – pronounced “pump,” before anyone suggests otherwise). This also broadens the coverage from just access to policies to the whole panoply of events – creation, access, modification and removal – which surround them.

That issue was, I think, fairly easily solved. The second could take more time.

Fino Napoleone is vice president of technology and services for Blockade Systems, a longtime player in the access control field but relatively new to identity management. Napoleone raised a question which I’ve mentioned in other contexts, but one which is front and center when we’re talking about identity management and a Policy Management Protocol: What exactly do we mean by “policy”?

Human resources in particular, but even the IT department, may first think of a loose-leaf binder filled with “dos and don’ts” when the subject of corporate or business policies comes up. No one has yet figured out a way to automate or computerize most of these rules of conduct, such as the “Business Casual Wear Policy” promulgated by CTG Resources, which tries to cover appropriate dress for all possible situations:

“The company is going to a business casual wear dress code for the full workweek. This policy is optional and employees may continue to wear regular business clothes as well. In going to business casual wear the Company would like all employees to feel comfortable, but does not want employees to appear less professional. Your attire should not make your co-workers and/or customers feel uncomfortable nor should it be distracting to others.”

https://www.cngcorp.com/career_opportunities/business_casual_wear_policy.html

There are just way too many variables and subjective judgments here. Network policies, on the other hand, are generally seen as a series of “if-then” logical gates that control who, what, when, where and how resources can be accessed.

There are also policies associated with regulatory compliance that are mandated by (usually) government legislation. The policy itself is more like the “Business Casual Wear Policy” but its implementation is probably a series of network, access-control, data acquisition and other computer-based if-then policies.

I’ve mentioned more than once that I’ve learned when interviewing people new to the identity management niche, but with experience in security products, that “policy” is one of the terms we need to define before we start to talk, as we probably have different ideas about its meaning. So here’s today’s assignment (you don’t expect me to do all the work, do you?): let’s come up with a definition of “policy” that satisfies our requirements while not being ambiguous and capable of being confused with other uses of the term. Even better, what about a completely different term?  Let’s hear your suggestions.