This note is an attempt to clear up misconceptions about, and mis-use of, the
term "meta-policy" that sprung up at XACML F2F #1 and have persisted afterwards.
I had much to do with introducing that term into the discussion, so please allow
me to try to clarify things.
The executive summary is:
Meta-policy, as described in [3, 4, 5], is *just one specific aspect* of the
much larger overall class of issues of "conflict" or "interference" [2] in
policy models and languages. We are trying to use it to describe the
overall class of "conflict resolution" [1]. We should stop using
"meta-policy" in this general sense.
We should use "meta-policy" only when we are specifically discussing
"policies about which policies can coexist in the system or what are
permitted attribute values for a valid policy." (see section 1.1 of [5]).
So we *shouldn't* use "meta-policy" to refer to the entire class of conflicts
that arise in the implementation and use of policy models [I've attached -- at
the end of this message -- some excerpts from [5] where it specifically
describes "meta-policy"]. Rather, we should use terms like "conflict" [1] and/or
"policy conflict" [3] to describe the overall class of issues.
We should use the terms "conflict resolution" [1] and/or "conflict detection and
resolution" [3, 4] to describe the overall class of remedial approaches.
Individual policies and/or their components can thus be described, if generally
appropriate, as "conflicting" [3]. In terms of specifics, [3, 4] go on to define
terms for specific forms of concflict, e.g. "modality conflicts",
"application-specific conflicts", which we may find useful recognize,
understand, and use.
JeffH
[1] S. Jajodia, P. Samarati, M.L. Sapino, and V.S. Subrahmanian,
``Flexible Support for Multiple Access Control Policies,''
in ACM Transactions on Database Systems, to appear.
http://sansone.crema.unimi.it/~samarati/Papers/tods-logic.ps
[2] P. Bonatti, S. De Capitani di Vimercati, and P. Samarati, ``An
Algebra for Composing Access Control Policies,''
in ACM Transactions on Information and System Security, to appear.
http://sansone.crema.unimi.it/~samarati/Papers/tissec02.ps
[3] E. Lupu and M. Sloman "Conflicts in Policy-based Distributed Systems
Management" IEEE Transactions on Software Engineering - Special Issue on
Inconsistency Management, Vol 25, No. 6 Nov. 1999, pp. 852-869.
http://www-dse.doc.ic.ac.uk/~mss/emil/tse.pdf
[4] N. Damianou, N. Dulay, E. Lupu, M Sloman, The Ponder Specification Language.
Workshop on Policies for Distributed Systems and Networks (Policy2001), HP Labs
Bristol, 29-31 Jan 2001.
http://www.doc.ic.ac.uk/~mss/Papers/Ponder-Policy01V5.pdf
[5] Ponder Language Specification v2.3
http://www-dse.doc.ic.ac.uk/Research/policies/files/PonderSpec.pdf
------------------------------------------------------------------------
specific descriptions of "meta-policy" given in [5]...
section 1.1
Meta-policies are policies about which policies can coexist in the system or
what are permitted attribute values for a valid policy. For example, a semantic
conflict may arise if there are two policies which increase and decrease
bandwidth allocation when the same event occurs, or a conflict of duty may arise
if there is a policy permitting the same manager to both sign cheques and
authorise payment.
section 4.2.2
Note that allowing negative and positive policies can lead to conflicts and the
need for precedence relationships between types of policies as discussed in
(Lupu 1999). These issues are not part of the language although the policy
precedence could be specified as a meta-policy.
section 6 "Meta-policies"
Meta-policies specify constraints, over a set of policies, on the permitted
types of policies or their policy elements.
---
end