Re: [xacml] What I learned from yesterday's telecon

[Tim] 1. A policy is the complete combination of rules governing access for a particular authorization decision request. A policy will often be too complicated for a human to work with it, in toto, directly.

This is 'applicable' policy. A policy is a set of rules + metapolicy.

[Tim] 2. A rule is the largest fragment of policy that a human can work with directly. Yes, the definitions are circular and, in the case of "rule", vague. Of course, there is no objective way of telling whether a fragment of policy is too big for a human to work with directly or not, but existing work suggests that a triple, containing a definition for resource, action and subject, fits the definition.

I do not think that there is agreed upon definition of a rule in the grlossary, but informaly (positive) rule states that Subject S is allowed to perform action A on resource R if conditions C are satisfied. It translates into triplet-like xml syntax.

[Tim] 3. A rule will often mimic the administrative GUI in which policy is written and analyzed.
4. A rule is an artifact entirely internal to the administrative system.

A rule is internal to the policy. Policy could be put into admin framework.

[Tim] 5. A policy is an artifact visible external to the administrative system.
6. In many cases, policies will actually turn out to be a set of rules combined in some relatively simple way, according to one of a few common meta-policies.

Agree, (6) is actiually a definition of a policy (without the word 'simple').

[Tim] One camp argues that rules should be reflected in the syntax of the language. Another camp says, the syntax of the language should be perfectly general. Then it will be possible, but not necessary, that a policy be constructed from sets of triples combined in some simple, prescribed, way. But, it will be up to implementations of policy-writing software to determine what the form of a policy will actually be. Both arguments have some appeal.

In the first case, it may be practical for developers to write and read policies directly in the language. This, at least will help with debugging the tools that others will use to manipulate instances of the language. However, I wouldn't expect a policy administrator to work directly with XACML instances. On the other hand, can we really be confident that limiting policies to be simple combinations of triples will be sufficiently general for all our uses?

Personally, I like the idea that a general logical combination of predicates or references to other policy instances would be a valid XACML instance. Implementations can always build their policies in the form of triples combined by simple logical formulae, if they wish, and these would be valid XACML. But, the language wouldn't limit us to this approach. Naturally, administrative GUIs would hide the details of XACML instances from administrators; quite possibly presenting it in the form of "rule triples". But, PDPs would be built to process arbitrarily-complicated combinations of predicates. The general predicate type could be extended to provide sub-types for resource predicates, subject predicates, etc..

In informative material, we can provide guidance to implementers on how to produce a policy based on rule triples with "grant", "deny" and "only_if" effects.

It would certainly be possible to specify a syntax for a rule, as well. But, this doesn't serve any interoperability goal.

Of course, limiting policies to the combination of triplets would not be sufficient. For that xacml rule structure should be made extensible. Extensibility of rule structure is similar to extensibility of predicate types. Because if you take a structured rule and smash it with a hammer, all the pieces will carry their initial semantic meaning in the types of predicates.

Even with general predicate syntax some structure is needed. We already have <target> element with <subjects> and <resources>. So predicate expressions that define applicability of a rule should be placed there, otherwise we do not need <target>. For example, suppose a rule says that administrators can read configuration file. Resource predicate expression req.resource=config.dat will go under <resources> and subject predicate expression subj.role='admin' will go under <subjects>.

Resource definition also needs structure, so that member-of an instance, member-of a class semantics are clear.

If we adopt general predicate expression structure, it should have enough information in it so that triplet form could be reconstructed. If we adopt simple syntactic shortcuts this general form will look like a triplet.

Simon

xacml message