Re: [xacml] RE: policy model, part 1

[Michiharu Kudoh <KUDO@jp.ibm.com>]

Basically, I agree to Carlisle's suggestion and Simon's proposal. I have a
comment on the structure of the policyStatement in v0.9 (not Carlisle's
proposal) that is structured:

<policyStatement>
  <target>
    <subjects>
    <resources>
    <actions>
  </target>
  <policy>
    <predicate>
</policyStatement>

From my viewpoint, the above structure should appear:

<ruleStatement>
  <target>
    <subjects>
    <resources>
    <actions>
  </target>
  <conditions>
</ruleStatement>

This goes with Carlisle's proposal. Since <policyStatement> in v0.9
corresponds to the rule statement, <policyStatement> should be
<ruleStatement> or <rule>. Since <policy> in the <ruleStatement> would be
misleading, it should be <conditionStatement> or <condition>. (my concern
is that <Condition> is also used in SAML in different meaning but I ignore
that here). I guess why <policy> is used here because the higher policy
structure (PolicyStatement in Carlisle's suggestion below)  reuses the
schema. My suggestion is to distinguish two structures and use <conditions>
(or more intuitive name ) <ruleStatement>?

Moreover, I don't quite understand why <predicate> is placed under
<subjects>, <resources>, <actions>, and <policy>. It does not seem to
convey a useful information. If it was an extension point, it could...

For the meaning of "any", I could live with either way: missing of
<subject> etc. or explicit element like <AnySubject>. Another option would
be to create <true> or <any> element in PredicateExpressionType. Then
<subjects><true/></subjects> could mean <AnySubject>.

As to Effect, I can understand the intention of this attribute and
understand that its primary purpose is a reference parameter in
meta-policy. I like to have this in explicit way like this. My concern is
that the usage of this Effect in meta-policy.

I don't quit understand the Carlisle's intention of "basic", "compoud",
"independent", and "dependent" of <Policy> in <PolicyStatement>. My
impression is that it would be better to focus more on specific use case as
well as to provide generic syntax and semantics. One of the typical way of
using a set of rules is to provide the notion of "rule set", that means
<Policy> refers a set of <ruleStatement> and they are combined with <or>
combinator.

<policyStatement>
  <policy>
    <or>
      <policyRef policyID="Policy1" .../>
      <policyRef policyID="Policy1" .../>
      <policyRef policyID="Policy1" .../>
   </or>
  </policy>
</policyStatement>

I think that the above notion should be represented using more specific
element like <ruleSet>. The rule set returns true (or permit?) if one of
the rule becomes true:

<ruleSet>
  <ruleRef ruleID="Rule1" .../>
  <ruleRef ruleID="Rule2" .../>
  <ruleRef ruleID="Rule3" .../>
</ruleSet>

I mean that the rule here represents the usual notion of rule used in
rule-based systems and rules in prolog language. As far as I know, rules
are combined by OR semantics and they are called rule set. I am not saying
that this is only the case we should provide but this is one of the typical
usage of rules.

Michiharu

IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428



From: Carlisle Adams <carlisle.adams@entrust.com> on 2002/02/20 06:51

To:   "'xacml@lists.oasis-open.org'" <xacml@lists.oasis-open.org>
cc:   "'simon@godik.com'" <simon@godik.com>
Subject:  [xacml] RE: policy model, part 1





Hi all,

Many thanks to Simon for writing up his view of the policy model -- his
thoughts are now much clearer to me!  I'm feeling optimistic because I
don't think that the various views floating around the TC are that far
apart.

I'm trying to put together a model that reconciles Simon's thoughts (which
are based, at least in part, on work by Michiharu, Pierangela, and Ernesto)
and what's in the v0.9 draft, but before going to XML syntax I'd like some
confirmation that we can reach consensus on the main features.  So, some
feedback on the following proposal would be welcome.

Carlisle.

A RuleStatement contains the following items.
  - a RuleCore, which is a triple ("subject", "action", "resource"),
although one or two of the components may be missing (meaning "any").  The
syntax would essentially be "RuleType" (that is, each component is a
PredicateExpressionType), but in practice we would expect that the
expressions used would be fairly simple ones.

  - a Condition, which is a combination of predicates that must evaluate to
true for this rule to fire.  The syntax would essentially be
PredicateExpressionType and may be arbitrarily complicated.

  - an Effect, which says how this rule is expected to contribute to a
policy result.  The syntax would essentially be EffectType, but extended to
include another enumeration.  The possibilities are

        - "Permit" (Simon's "authorization" rule which, if TRUE, will
contribute to a "Permit" decision but if FALSE may not cause a "Deny"),

        - "RequiredPermit" (Simon's "restriction" rule which must be TRUE
before a "Permit" decision can be returned and if FALSE will force a
"Deny"), and

        - "Deny", which, if TRUE, will cause a "Deny" decision to be
returned.

A PolicyStatement contains the following items.
  - an Identifier, so that it may be referenced.
  - a Name (optional).
  - a Comment (optional).
  - perhaps some other items (e.g., Issuer, or IssueInstant), even if these
might also be part of the SAML assertion envelope (see MetaPolicyStatement
below...).

  - a Target, which specifies the applicability of the policy.  The syntax
would essentially be RuleType.  Each component (i.e., "subject", "action",
"resource") is, in the worst case, the union (i.e., the "or") of the
corresponding components in the included RuleCore or Target expressions,
but in many cases a simpler equivalent expression may be found.

  - a Policy.  There are four possibilities for this:
        - a "basic", "independent" policy
        - a "basic", "dependent" policy
        - a "compound", "independent" policy
        - a "compound", "dependent" policy

Definitions:
  - a "basic" policy is a combination of rules;
  - a "compound" policy is a combination of policies (this is what we've
called a "base policy" or a "higher-level policy" in the past, but
"compound" may be more intuitive...);

  - an "independent" policy explicitly includes the combining algorithm and
therefore can be evaluated entirely on its own;

  - a "dependent" policy points to (i.e., references) an external, generic
combining algorithm (a metapolicy) and therefore can be evaluated only in
conjunction with that metapolicy.

A MetaPolicyStatement contains the following items.
  - an Identifier, so that it may be referenced.
  - a Name (optional).
  - a Comment (optional).
  - an Algorithm for combining predicates, which may be predicates about
rules (such as "Permit" and "Deny") or predicates about policies (such as
"Issuer" or "IssueInstant").  The syntax would essentially be
PredicateExpressionType.