[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]