[xacml] Another proposal (a good one this time)

[Tim Moses <tim.moses@entrust.com>]

Title: Another proposal (a good one this time)

Colleagues - Here is a new proposal.  I believe it addresses many of the issues we are wrestling with in a self-consistent manner.  It is one that I (personally) can live with as a point from which to start refining the schema.  I would be interested to know whether others can "live with" it, too.  All the best.  Tim.

Proposal

There is no syntactic distinction between a rule and a policy.  A rule is simply a small policy.  So, I'll use the term "policy" exclusively for the remainder of this discussion.

A policy statement contains:
· a policyId;
· a target;
· an effect;
· a metaPolicyRef and
· a condition.

Policy meta-data (such as issuer and issue instant) are conveyed in the saml statement wrapper.

Target defines the set of names for the:
· resources;
· subjects and
· actions
to which the policy statement applies.  If the policy statement applies to all entities of a particular type, then the target definition is the root of the applicable name space.  An XACML PDP MUST verify that the names of the resources, subjects and actions specified in an authorization decision request are each included in the target of the policy statement that it uses to evaluate the request.

MetaPolicyRef specifies the meta-policy by which the policy statement MAY be combined with other policy statements.

Condition is a general expression of predicates of attributes.  It SHOULD NOT duplicate the exact predicates implied by target.  Therefore, it MAY be null.

Policy statements may be combined provided that their metaPolicyRefs are identical and that their targets are in identical name spaces.  This SHALL be done by including the conditions from the source policy statements in the condition of the combined policy statement, in accordance with the meta-policy.  (See draft-xacml-v0.9, Section 6 for an example of a meta-policy).

The target of the combined policy statement can be calculated from the targets of the source policy statements.  Two approaches are permitted:

· the target of the combined policy statement MAY contain the unions of the target definitions for resource, subject and action that are contained in the source policy statements; or

· the target of the combined policy statement MAY contain the intersections of the definitions.
In the former case, the targets from the source policy statements MUST be included in the form of conditions in the combined policy statement.  In the latter case, this step MAY be omitted.  In the former case, inapplicable predicates should not be encountered.  In the latter case, inapplicable predicates may be encountered.

The effect of the combined policy is defined by the meta-policy.

The syntax of a combined policy statement is identical to that of a source policy statement.

There is an alternative representation for a combined policy, called a policy manifest.  It contains:
· a policyId;
· a target;
· a metaPolicyRef and
· a list of policy definitions.
A policy definition identifies a policy statement by meta-data, (e.g. name).

A policy manifest can be converted to a policy statement at any time, by applying the identified meta-policy to the policy statements identified by the policy definitions.  The resulting policy statement MUST contain a target computed from the target values in the actual versions of the source policy statements used in the conversion, whereas, the target in the manifest SHOULD be computed from the target values in the actual versions of the source policy statements at the time the manifest was prepared.

The significance of the two representations is that, in the first case, the policy statement is generated at the time of preparing the representation, whereas, in the second case, the policy statement can be generated (using the latest versions of the source policy statements) immediately prior to evaluation.  PDPs SHOULD support both representations.

-----------------------------------------
Tim Moses
Tel: 613.270.3183