RE: [xacml] Minutes from March 2002 Face-to-Face

[Carlisle Adams <carlisle.adams@entrust.com>]

Title: RE: [xacml] Minutes from March 2002 Face-to-Face

Hi Anne,

----------
From:   Anne Anderson[SMTP:Anne.Anderson@Sun.com]
Sent:   Wednesday, March 13, 2002 4:11 PM
To:     XACML TC
Subject:        [xacml] Minutes from March 2002 Face-to-Face

The draft minutes are attached.  Please send me corrections or
additions.

 
Thank you very much for the thorough and comprehensive job on the minutes!  I have a couple of comments, which are embedded below (a lot of your text is excluded in order to keep this message short).

AGREEMENTS REACHED:

<rule>
  <target>
    <subject>..</subject>
    <action>..</action>
    <resource>..</resource>
  </target>
  <ruleMetaData name="anyURI" value="any"/>
  <condition>
    [arbitrary boolean predicate over subject, action, resource]
  </condition>
  <effect>..</effect>     [CHOICE: Permit or Deny]
  <obligations>           [OPTIONAL]
    <obligation>
    <obligation>
    ...
  </obligations>
</rule>

 
I don't recall us agreeing that <ruleMetaData> is included in a <rule>.  I think it only goes in <ruleSet>.  I remember Tim saying at one point that in v0.10 a rule already contains meta-data, but he only meant that along with things like <condition> and <effect>, it includes <ruleId>, <ruleName>, and <comment>.  I don't think he meant "meta-data" in the sense we use it in <ruleSet> (i.e., as something that a combiner uses to determine how to combine this rule with other rules).

So, I think that <ruleMetaData> needs to be removed from the above schema for <rule>.  Alternatively, it's fine with me if we keep it in, but then it probably makes sense for <effect> to be one possibility for <ruleMetaData>, rather than a completely separate element.

<rule> Truth Table:

  Target  Condition  Effect
  ------  ---------  ------------
  T       T          [Effect]
  T       F          Inapplicable
  T       Indet.     Indet.
  F       T          Inapplicable
  F       F          Inapplicable
  F       Indet.     Inapplicable

 
We should probably do what Hal suggested and put "match" or "no-match" in the Target column, rather than T or F (i.e., the same as you have in the <policyStatement> Evaluation Table).

policyStatement and policyCombinationStatement allow determinism:
their "combiner"s can control order or completeness of
evaluation.  If determinism is desired at the expense of
performance, then the combiner algorithms can force evaluation of
all rules and policies.

Just to be clear, we should probably explicitly talk about obligations in the text above (i.e., "policyStatement and policyCombinationStatement allow determinism with respect to obligations: ...  If determinism of obligations is desired...").  I would prefer this because we want it to be crystal clear to everyone that we always expect determinism of the *result* of evaluation (that is, permit or deny or inapplicable, whenever all relevant input values are available).  The only thing that might not be deterministic (depending on desire for performance/efficiency) is the exact set of obligations that will be returned to the PEP.

Finally, the list of AGREEMENT versus OPEN versus "?" at the top of the summary includes the word "policySetCombination", but this should probably be "policySetCombiner".

Thanks again for capturing and summarizing two days of discussion so effectively!

Carlisle.