OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] oasis-xacml-2_0-core-spec-wd-08.zip






Polar,

I should have explained in more exact way. First, I list several text
changes I would like to see. The modified sentence relevant to rule is
marked as >> ... <<.
(Since my English is not good, please read between lines!)
----------------------------------------------------
I would add Section 3.3.1.4 Obligation as follows:

3.3.1.4 Obligation
>>Obligation of the rule indicates the rule-writer's additional intention
to "True" evaluation for the rule in addition to effect.<<

I would change Section 3.3.2.3 Obligations as follows:

3.3.2.3 Obligations
>>When a PDP evaluates a rule containing obligations, it returns
obligations in the way described in each rule-combining algorithm.<<
When a PDP evaluates a policy containing obligations, it returns certain of
those obligations to the PEP in the response context. Section 7.11 explains
which obligations are to be returned.

I would change 7.11 Obligations as follows:

7.11 Obligations
A >>rule<<, policy or policy set may contain one or more obligations. >>In
the case of the rule, an obligation specified in the rule that is evaluated
and "True" evaluation for the rule SHALL be collected per each effect of
the rule. When the enclosing policy is evaluated, an obligation specified
both in the policy and the collected from the rule(s) SHALL be passed up to
the next level of evaluation only if the decision of the rule combining
algorithm matches the value of the xacml:FulfillOn attribute of the
obligation in the policy and the corresponding obligations collected from
the rule(s) being evaluated.<<
... continue to the original text

So I try to answer the question you wrote.

>First of all, what does "if this rule fires" means?
Fire means "True" evaluation for the rule.

>Does that mean that this rule's <target> is true?,
Yes.

>Does that mean this rule's <target> got "evaluated"?
No.

>Does it mean that this rule's <Condition> is true?
Yes.

>Does it mean that the <Condition> is "evaluated" (whether it becomes true
>or false)?
<Condition> must become true.

>And what does "evaluated" mean? Do you consider a rule "firing" if its
>been evaluated once and cached for later decisions?
Again, fire means "True" evaluation for the rule.

>So, if the rule's <Condition> gets evaluated to False, and its Effect is
>(well who cares), and its obligation is FullFillOn="Deny", does the
>obligation apply if the final decision of the policy is Deny?
Since fire means "True" evaluation for the rule, the obligation
specified in the rule never be applied even if the final decision
of the policy is Deny.

>What about the reverse situation, the <Condition> evaluates to False and
>the rule's effect is (again, who cares), and its obligation is
>FulFillOn="Permit", does its obligation apply if the final decision of the
>policy is Permit?
No, its obligation never apply even if the final decision of the policy
is Permit.

>Any answers that may accompany these questions into the spec?
The spec should clearly state.

>Before, it was easy and simplistic. The rule combining algorithm decides
>the Effect of the Policy by combining the determined Effects of the rules.
>You get your obligations from the policy based on the final effect of the
>combining algorithm. What more do you need here?
To me, it is still easy and simplistic. The complication of the rule
combining algorithm after introducing the obligation is nearly the same
with that of the policy combining algorithm for XACML 1.0. The policy
combining algorithm for 1.0 has to deal with similar situation as we face
here after all. For example,

<PolicySet Alg="ordered-permit-overrides">
  <PolicyIdReference>policy1</>
  <PolicyIdReference>policy2</>
  <PolicyIdReference>policy3</>
  <Obligations>
    <Obligation ObligatoinId="encryption" FulfillOn="Permit"/>
  </Obligations>
</Policy>

The policy combining algorithm has to remember the decision and the
obligation of each policy (policy1,2,3). Suppose the policy1 returns "Deny"
with "email", the policy 2 is not applicable, and the policy3 returns
"Permit" with "log". The policy combining algorithm returns  "Permit" with
"log" and "encryption" from the definition of 3.3.3.2 and 7.11. The similar
semantics has been specified in XACML 1.0, though it happens in PolicySet.

Best,
Michiharu



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]