OASIS eXtensible Access Control Markup Language (XACML) TC

All, Here are some examples which illustrate the points I was trying to make during the TC meeting last week. The first example intends to show why it is necessary to evaluate the children in order to determine the flavor of Indeterminate from a target. Consider the following policy: Policy: target: resource-id = printer subject-id = alice Rule[Effect=Permit] Assume we have the following request: Subject: subject-id = alice Resource: resource-id = printer For this request this policy would say Permit. Now consider this policy: Policy: target: resource-id = bank-account subject-risk-level = HIGH Rule[Effect=Deny] This policy would say NotApplicable for the same request as above. Now, assume that we collect the two policies in a policy set: PolicySet Target: subject-location[MustBePresent='true'] = office Policy: target: resource-id = printer subject-id = alice Rule[Effect=Permit] Policy: target: resource-id = bank-account subject-risk-level = HIGH Rule[Effect=Deny] Now, let's evaluate this policy against the example request from above. The target of the policy set will be Indeterminate because the subject-location attribute is missing. Now, which flavor of Indeterminate should it be? It should be Indeterminate{P} since only a permit could have been produced if the target would not have failed. And we know that only if we evaluate the children. Note that simply scanning the policy tree for effects would incorrectly conclude that the policy might have evaluated to a Deny for this request. Now, there was another issue which was discussed at the meeting, namely that Paul had an idea that instead of having to actually evaluate all the children, one could think of the policy is being transformed. I need to bring up another example to illustrate that. (I did not want to mix two issues in the same example policy.) Consider this policy set: PolicySet Target: subject-location[MustBePresent='true'] = office Policy[CombAlg='deny-unless-permit']: Target[empty] Rule[Effect=Permit] target: resource-id = printer subject-id = alice Rule[Effect=Deny] target: resource-id = bank-account subject-risk-level = HIGH Again, let's evaluate the policy set with the example request from above. The policy set target is indeterminate, so the policy set is Indeterminate as a whole. If we would evaluate the children to determine the flavor of Indeterminate, we would get Indeterminate{P}, like above because the rule about bank accounts does not apply. Now, Paul thought one could rewrite this policy set by adding the expression from the policy set target in each leaf rule as a condition. However, I pointed out that it won't give the same result because of the combining algorithms. In this case, the rewritten policy would be: PolicySet Target[empty] Policy[CombAlg='deny-unless-permit']: Target[empty] Rule[Effect=Permit] target: resource-id = printer subject-id = alice condition: subject-location[MustBePresent='true'] = office Rule[Effect=Deny] target: resource-id = bank-account subject-risk-level = HIGH condition: subject-location[MustBePresent='true'] = office Íf we evaluate this policy set against the example request, we get Indeterminate in both rules because of the missing attribute in their conditions. However, the 'deny-unless-permit' algorithm is going to change that to a Deny for the policy which contains the rules, so overall we get Deny, which is different from the policy set before we transformed. The question Paul brought up during the meeting was whether this was intended. Clearly that is what the spec says happens since the evaluation tables allow a combining algorithm to make a decision among several conflicting decisions. I guess what Paul is thinking about is that there should be some kind of "linearity" requirement, by which certain properties of the policy are immutable under certain types of transformations in the policy. However, there are currently no general requirements on the algorithms which would guarantee that certain decisions are not overridden. I don't think there should be either. Best regards, Erik

Thanks, Erik, for the very clear explanation and examples. The flexibility of XACML makes it possible to do very strange things, and even without doing anything strange even the simplest policy set can quickly become complicated. The policy writer already has to think hard about policy structure, combining-algorithms, attribute tests, and the MustBePresent attribute. He should not have to worry about getting different results depending on whether he happens to put an attribute test in a Target or in a Condition. But it doesn't appear the TC is inclined to address this problem right now. Erik's proposal (wd-19 section 7.13, Table 7) seems to be a reasonable approach that will not cause too many surprises. In the longer term the TC should work out a comprehensive logical framework that explicitly either confirms or denies the "policy equivalence" (or "linearity" as Erik called it) between a policy with a non-empty target and the same policy with an empty target and the attribute tests distributed to the descendant conditions (with appropriate syntactic modifications). Hal has said the TC has avoided previous attempts to define "policy equivalence", but I assume that was in general, not for this specific issue. However, I don't think we can avoid the question of whether an indeterminate target should override a "permit-unless-deny" or "deny-unless-permit" combining algorithm on the parent of the indeterminate target. Erik's example does not include the combining-algorithm of the top policy. A policy writer who uses one of these algorithms never wants to see "Indeterminate" or "NotApplicable". Either we must amend wd-19 Table 7 to honor these algorithms, or revise the definition of these algorithms to account for indeterminate targets. (Note that if we adopted the notion of policy equivalence and evaluated all descendant rules as "Indeterminate", this would not be a problem.) Regards, --Paul > -----Original Message----- > From: Erik Rissanen [ mailto:erik@axiomatics.com ] > Sent: Monday, April 25, 2011 06:55 > To: xacml > Subject: [xacml] The Indeterminate flavors question > > All, > > Here are some examples which illustrate the points I was trying to make > during the TC meeting last week. > > The first example intends to show why it is necessary to evaluate the > children in order to determine the flavor of Indeterminate from a > target. > > Consider the following policy: > > Policy: > target: resource-id = printer > subject-id = alice > Rule[Effect=Permit] > > Assume we have the following request: > > Subject: > subject-id = alice > Resource: > resource-id = printer > > For this request this policy would say Permit. > > Now consider this policy: > > Policy: > target: resource-id = bank-account > subject-risk-level = HIGH > Rule[Effect=Deny] > > This policy would say NotApplicable for the same request as above. > > Now, assume that we collect the two policies in a policy set: > > PolicySet > Target: subject-location[MustBePresent='true'] = office > Policy: > target: resource-id = printer > subject-id = alice > Rule[Effect=Permit] > Policy: > target: resource-id = bank-account > subject-risk-level = HIGH > Rule[Effect=Deny] > > Now, let's evaluate this policy against the example request from above. > > The target of the policy set will be Indeterminate because the > subject-location attribute is missing. Now, which flavor of > Indeterminate should it be? It should be Indeterminate{P} since only a > permit could have been produced if the target would not have failed. > And > we know that only if we evaluate the children. Note that simply > scanning > the policy tree for effects would incorrectly conclude that the policy > might have evaluated to a Deny for this request. > > > Now, there was another issue which was discussed at the meeting, namely > that Paul had an idea that instead of having to actually evaluate all > the children, one could think of the policy is being transformed. I > need > to bring up another example to illustrate that. (I did not want to mix > two issues in the same example policy.) > > Consider this policy set: > > PolicySet > Target: subject-location[MustBePresent='true'] = office > Policy[CombAlg='deny-unless-permit']: > Target[empty] > Rule[Effect=Permit] > target: resource-id = printer > subject-id = alice > Rule[Effect=Deny] > target: resource-id = bank-account > subject-risk-level = HIGH > > > Again, let's evaluate the policy set with the example request from > above. The policy set target is indeterminate, so the policy set is > Indeterminate as a whole. If we would evaluate the children to > determine > the flavor of Indeterminate, we would get Indeterminate{P}, like above > because the rule about bank accounts does not apply. > > Now, Paul thought one could rewrite this policy set by adding the > expression from the policy set target in each leaf rule as a condition. > However, I pointed out that it won't give the same result because of > the > combining algorithms. In this case, the rewritten policy would be: > > PolicySet > Target[empty] > Policy[CombAlg='deny-unless-permit']: > Target[empty] > Rule[Effect=Permit] > target: resource-id = printer > subject-id = alice > condition: subject-location[MustBePresent='true'] = office > Rule[Effect=Deny] > target: resource-id = bank-account > subject-risk-level = HIGH > condition: subject-location[MustBePresent='true'] = office > > Íf we evaluate this policy set against the example request, we get > Indeterminate in both rules because of the missing attribute in their > conditions. However, the 'deny-unless-permit' algorithm is going to > change that to a Deny for the policy which contains the rules, so > overall we get Deny, which is different from the policy set before we > transformed. > > The question Paul brought up during the meeting was whether this was > intended. Clearly that is what the spec says happens since the > evaluation tables allow a combining algorithm to make a decision among > several conflicting decisions. I guess what Paul is thinking about is > that there should be some kind of "linearity" requirement, by which > certain properties of the policy are immutable under certain types of > transformations in the policy. > > However, there are currently no general requirements on the algorithms > which would guarantee that certain decisions are not overridden. I > don't > think there should be either. > > Best regards, > Erik > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Hi Erik, Maybe I missed something along the way, but I do not understand the meaning of combining algorithm value in Table 7.  Is this defined somewhere? I do see a number of phrases of the type:   ... then the policy-combining algorithm specified in the policy set    SHALL determine the policy set value or ... then the rule-combining algorithm specified in the policy   SHALL determine the policy value One problem might be that the Indeterminate(x) construct is not defined until section C.1. If we take that as the basis of how the value of the combining algorithm is determined, which makes sense to me, then I think we can conclude that the rules do not have to be evaluated when the Target is Indeterminate, however, their effects must be examined in order to determine the type of Indeterminate that should be returned. This then becomes the value in the left hand column of table 7,  and I think that everything is consistent. So, recommendation: have ref in section 7, prior to Table 7, pointing to section C.1 for the defns of Ind(x).     Thanks,     Rich On 4/25/2011 9:22 AM, Tyson, Paul H wrote: 3898C40CCD069D4F91FCD69C9EFBF096063CB8A0@txamashur004.ent.textron.com type= cite > Thanks, Erik, for the very clear explanation and examples. The flexibility of XACML makes it possible to do very strange things, and even without doing anything strange even the simplest policy set can quickly become complicated. The policy writer already has to think hard about policy structure, combining-algorithms, attribute tests, and the MustBePresent attribute. He should not have to worry about getting different results depending on whether he happens to put an attribute test in a Target or in a Condition. But it doesn't appear the TC is inclined to address this problem right now. Erik's proposal (wd-19 section 7.13, Table 7) seems to be a reasonable approach that will not cause too many surprises. In the longer term the TC should work out a comprehensive logical framework that explicitly either confirms or denies the policy equivalence (or linearity as Erik called it) between a policy with a non-empty target and the same policy with an empty target and the attribute tests distributed to the descendant conditions (with appropriate syntactic modifications). Hal has said the TC has avoided previous attempts to define policy equivalence , but I assume that was in general, not for this specific issue. However, I don't think we can avoid the question of whether an indeterminate target should override a permit-unless-deny or deny-unless-permit combining algorithm on the parent of the indeterminate target. Erik's example does not include the combining-algorithm of the top policy. A policy writer who uses one of these algorithms never wants to see Indeterminate or NotApplicable . Either we must amend wd-19 Table 7 to honor these algorithms, or revise the definition of these algorithms to account for indeterminate targets. (Note that if we adopted the notion of policy equivalence and evaluated all descendant rules as Indeterminate , this would not be a problem.) Regards, --Paul -----Original Message----- From: Erik Rissanen [ mailto:erik@axiomatics.com ] Sent: Monday, April 25, 2011 06:55 To: xacml Subject: [xacml] The Indeterminate flavors question All, Here are some examples which illustrate the points I was trying to make during the TC meeting last week. The first example intends to show why it is necessary to evaluate the children in order to determine the flavor of Indeterminate from a target. Consider the following policy: Policy: target: resource-id = printer subject-id = alice Rule[Effect=Permit] Assume we have the following request: Subject: subject-id = alice Resource: resource-id = printer For this request this policy would say Permit. Now consider this policy: Policy: target: resource-id = bank-account subject-risk-level = HIGH Rule[Effect=Deny] This policy would say NotApplicable for the same request as above. Now, assume that we collect the two policies in a policy set: PolicySet Target: subject-location[MustBePresent='true'] = office Policy: target: resource-id = printer subject-id = alice Rule[Effect=Permit] Policy: target: resource-id = bank-account subject-risk-level = HIGH Rule[Effect=Deny] Now, let's evaluate this policy against the example request from above. The target of the policy set will be Indeterminate because the subject-location attribute is missing. Now, which flavor of Indeterminate should it be? It should be Indeterminate{P} since only a permit could have been produced if the target would not have failed. And we know that only if we evaluate the children. Note that simply scanning the policy tree for effects would incorrectly conclude that the policy might have evaluated to a Deny for this request. Now, there was another issue which was discussed at the meeting, namely that Paul had an idea that instead of having to actually evaluate all the children, one could think of the policy is being transformed. I need to bring up another example to illustrate that. (I did not want to mix two issues in the same example policy.) Consider this policy set: PolicySet Target: subject-location[MustBePresent='true'] = office Policy[CombAlg='deny-unless-permit']: Target[empty] Rule[Effect=Permit] target: resource-id = printer subject-id = alice Rule[Effect=Deny] target: resource-id = bank-account subject-risk-level = HIGH Again, let's evaluate the policy set with the example request from above. The policy set target is indeterminate, so the policy set is Indeterminate as a whole. If we would evaluate the children to determine the flavor of Indeterminate, we would get Indeterminate{P}, like above because the rule about bank accounts does not apply. Now, Paul thought one could rewrite this policy set by adding the expression from the policy set target in each leaf rule as a condition. However, I pointed out that it won't give the same result because of the combining algorithms. In this case, the rewritten policy would be: PolicySet Target[empty] Policy[CombAlg='deny-unless-permit']: Target[empty] Rule[Effect=Permit] target: resource-id = printer subject-id = alice condition: subject-location[MustBePresent='true'] = office Rule[Effect=Deny] target: resource-id = bank-account subject-risk-level = HIGH condition: subject-location[MustBePresent='true'] = office Íf we evaluate this policy set against the example request, we get Indeterminate in both rules because of the missing attribute in their conditions. However, the 'deny-unless-permit' algorithm is going to change that to a Deny for the policy which contains the rules, so overall we get Deny, which is different from the policy set before we transformed. The question Paul brought up during the meeting was whether this was intended. Clearly that is what the spec says happens since the evaluation tables allow a combining algorithm to make a decision among several conflicting decisions. I guess what Paul is thinking about is that there should be some kind of linearity requirement, by which certain properties of the policy are immutable under certain types of transformations in the policy. However, there are currently no general requirements on the algorithms which would guarantee that certain decisions are not overridden. I don't think there should be either. Best regards, Erik --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

> -----Original Message----- > From: Tyson, Paul H [ mailto:PTyson@bellhelicopter.textron.com ] > Sent: Monday, April 25, 2011 3:22 PM > To: Erik Rissanen; xacml > Subject: RE: [xacml] The Indeterminate flavors question > > In the longer term the TC should work out a comprehensive logical > framework that explicitly either confirms or denies the "policy > equivalence" (or "linearity" as Erik called it) between a policy with a > non-empty target and the same policy with an empty target and the > attribute tests distributed to the descendant conditions (with > appropriate syntactic modifications). Hal has said the TC has avoided > previous attempts to define "policy equivalence", but I assume that was > in general, not for this specific issue. I agree that policy equivalence/linearity makes a lot of sense from the perspective of being able to understand XACML policies. It might also enable certain optimizations in implementations.

Hi, (Tried to post this earlier, but there was an outage in the OASIS email servers it seems.) Maybe, but it also goes against current concepts in XACML and is not that easy to define. - It puts restrictions on combining algorithms. For instance the permit-unless-deny and deny-unless-permit algorithms would be disallowed. - I haven't thought it through properly, but I suspect that of the four possible decisions, we can make only one decision "linear". So, if we for instance make Indeterminate linear, then NotApplicable cannot be so because at any given level the conflict between a notapplicable and indeterminate has to be resolved. If there is a target T1 which causes Indeterminate and a target T2 which causes NotApplicable, depending on which one we push down in the equivalent policy, assuming we push down only one of them, we could get different results since given any single definition of priority, only one of them can truly become linear. So linearity probably is not possible to achieve. (If I got this right...) - The equivalency conditions are not that simple since the order of expressions in the equivalent policies matter, so we would need to be very careful about this. For instance, a condition with an AND expression short circuits, so we must take care to join the pushed down conditional expressions properly in relation to everything else which exists or is pushed down. Can probably be done, but not very simple, which raises the following question: - What specifically is the proposal on the table and for what benefit? Is the proposal that we define some transformation in the spec? For what purpose? Is it that we require certain meta conditions on combining algorithms so some transformation supposedly holds? Which transformation is this and what are the conditions on the algorithms? Best regards, Erik On 2011-04-29 09:28, remon.sinnema@emc.com wrote: >> -----Original Message----- >> From: Tyson, Paul H [ mailto:PTyson@bellhelicopter.textron.com ] >> Sent: Monday, April 25, 2011 3:22 PM >> To: Erik Rissanen; xacml >> Subject: RE: [xacml] The Indeterminate flavors question >> >> In the longer term the TC should work out a comprehensive logical >> framework that explicitly either confirms or denies the "policy >> equivalence" (or "linearity" as Erik called it) between a policy with a >> non-empty target and the same policy with an empty target and the >> attribute tests distributed to the descendant conditions (with >> appropriate syntactic modifications). Hal has said the TC has avoided >> previous attempts to define "policy equivalence", but I assume that was >> in general, not for this specific issue. > I agree that policy equivalence/linearity makes a lot of sense from the perspective of being able to understand XACML policies. > It might also enable certain optimizations in implementations. > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >

> -----Original Message----- > From: Erik Rissanen [ mailto:erik@axiomatics.com ] > Sent: Thursday, May 05, 2011 03:09 > To: xacml@lists.oasis-open.org > Subject: Re: [xacml] Re: Policy equivalence [was: The Indeterminate > flavors question] > > Hi, > > (Tried to post this earlier, but there was an outage in the OASIS email > servers it seems.) > > Maybe, but it also goes against current concepts in XACML and is not > that easy to define. > > - It puts restrictions on combining algorithms. For instance the > permit-unless-deny and deny-unless-permit algorithms would be > disallowed. I think it makes these algorithms behave consistently with their current definition, which lead one to believe that they should never return Indeterminate or NotApplicable from the *policy* or *policyset*. As Erik interprets these algorithms, they apply only to the contained rules (or policies/policysets), and not to the entire Policy or PolicySet element they are attached to (including any immediate Target). This may be a legitimate interpretation--it just isn't clear in the spec, and makes these algorithms useless for implementing a rigid decision bias in a policyset. > > - I haven't thought it through properly, but I suspect that of the four > possible decisions, we can make only one decision "linear". So, if we > for instance make Indeterminate linear, then NotApplicable cannot be so > because at any given level the conflict between a notapplicable and > indeterminate has to be resolved. If there is a target T1 which causes > Indeterminate and a target T2 which causes NotApplicable, depending on > which one we push down in the equivalent policy, assuming we push down > only one of them, we could get different results since given any single > definition of priority, only one of them can truly become linear. So > linearity probably is not possible to achieve. (If I got this right...) This is a research opportunity, to see whether a well-defined transformation of Targets to Conditions (see below) will actually cause this sort of ambiguity in any type of policy. And if there is such a possibility, I would suspect that our definition of policy evaluation is at fault, and should be revised to ensure consistency. > > - The equivalency conditions are not that simple since the order of > expressions in the equivalent policies matter, so we would need to be > very careful about this. For instance, a condition with an AND > expression short circuits, so we must take care to join the pushed down > conditional expressions properly in relation to everything else which > exists or is pushed down. Can probably be done, but not very simple, > which raises the following question: Order of evaluation should be a processing convenience only, not a cause of different results. I believe the current policy evaluation specification, with its implied order of evaluation, is somewhat accidental and is not consistent with a purely logical evaluation of the Boolean schema represented by a policy. > > - What specifically is the proposal on the table and for what benefit? > Is the proposal that we define some transformation in the spec? For > what > purpose? Is it that we require certain meta conditions on combining > algorithms so some transformation supposedly holds? Which > transformation > is this and what are the conditions on the algorithms? Using XACML 3.0 syntax and pseudo-xslt, here is the intended transformation, which is irrespective of combining algorithms: ======== Policy equivalence algorithm ============= Target -> Apply[@FunctionId='and']. AnyOf -> Apply[@FunctionId='or'] AllOf -> Apply[@FunctionId='and'] Match -> Apply[@FunctionId='any-of'], with children: Function[@FunctionId=current()/@MatchId] AttributeValue -> copy Match/AttributeValue AttributeDesignator -> copy Match/AttributeDesignator Replace the existing Target element with an empty Target, then for each descendent Rule element: If there is a Condition element, then replace existing Condition/* element with Apply[@FunctionId='and'] and use existing Condition/* element as first child and the generated Apply element as 2nd child. If no Condition, add a Condition element with the generated Apply element as child. ======== End of Policy equivalence algorithm ======== I believe AttributeSelector could be handled in the same manner as AttributeDesignator, but I don't have enough experience to say for sure. My lemma is that all policies transformed in this way should evaluate to the same decision as the original policy (given the same request context). And if not, there is a defect in the policy evaluation specification. Regards, --Paul

So it seems to me we have two issues here: 1. We need to make an immediate decision about the text in core 3.0 which describes the processing around extended indeterminate. 2. The requirements and possible implementation strategies around "policy equivalence". Is it desirable? Is it practical? I would like to comment briefly on each. 1. Looking at WD 19, section C.1 seems to me to be ambiguous as to how to which flavor of Indeterminate is to be propagated. Here is the text (unchanged from prior drafts): ---- Some combining algorithms are defined in terms of an extended set of “Indeterminate” values. For these algorithms, the PDP MUST keep track of the extended set of “Indeterminate” values during rule and policy combining. The extended set associated with the “Indeterminate” contains the potential effect values which could have occurred if there would not have been an error causing the “Indeterminate”. The possible extended set “Indeterminate” values are · “Indeterminate{D}”: an “Indeterminate” from a policy or rule which could have evaluated to “Deny”, but not “Permit” · “Indeterminate{P}”: an “Indeterminate” from a policy or rule which could have evaluated to “Permit”, but not “Deny” · “Indeterminate{DP}”: an “Indeterminate” from a policy or rule which could have evaluated to “Deny” or “Permit”. The combining algorithms which are defined in terms of the extended “Indeterminate” make use of the additional information to allow for better treatment of errors in the algorithms. The following define the base cases for rule evaluation: · A rule which evaluates to “Indeterminate” and has Effect=”Permit” results in an “Indeterminate{P}”. · A rule which evaluates to “Indeterminate” and has Effect=”Deny” results in an “Indeterminate{D}”. ---- Does the language "could have evaluated to ..." mean for any possible inputs or for the current request context? Does the language 'A rule which evaluates to "Indeterminate"' mean that there is specifically an indeterminate in the target or condition of the rule or does it also include the case of an indeterminate in a parent policy? 2. I suspect that it is impossible to produce the "policy equivalence" property Paul proposed for an arbitrary combination of combining algorithms. At least it is impossible while keeping the steps of calculating rule value, policy value and combining algorithms cleanly separated. I also question the real world value of implementing this functionality. Hal > -----Original Message----- > From: Tyson, Paul H [ mailto:PTyson@bellhelicopter.textron.com ] > Sent: Monday, April 25, 2011 9:22 AM > To: Erik Rissanen; xacml > Subject: RE: [xacml] The Indeterminate flavors question > > > Thanks, Erik, for the very clear explanation and examples. > > The flexibility of XACML makes it possible to do very strange > things, and even without doing anything strange even the > simplest policy set can quickly become complicated. The > policy writer already has to think hard about policy > structure, combining-algorithms, attribute tests, and the > MustBePresent attribute. He should not have to worry about > getting different results depending on whether he happens to > put an attribute test in a Target or in a Condition. > > But it doesn't appear the TC is inclined to address this > problem right now. Erik's proposal (wd-19 section 7.13, > Table 7) seems to be a reasonable approach that will not > cause too many surprises. > > In the longer term the TC should work out a comprehensive > logical framework that explicitly either confirms or denies > the "policy equivalence" (or "linearity" as Erik called it) > between a policy with a non-empty target and the same policy > with an empty target and the attribute tests distributed to > the descendant conditions (with appropriate syntactic > modifications). Hal has said the TC has avoided previous > attempts to define "policy equivalence", but I assume that > was in general, not for this specific issue. > > However, I don't think we can avoid the question of whether > an indeterminate target should override a > "permit-unless-deny" or "deny-unless-permit" combining > algorithm on the parent of the indeterminate target. Erik's > example does not include the combining-algorithm of the top > policy. A policy writer who uses one of these algorithms > never wants to see "Indeterminate" or "NotApplicable". > Either we must amend wd-19 Table 7 to honor these algorithms, > or revise the definition of these algorithms to account for > indeterminate targets. (Note that if we adopted the notion > of policy equivalence and evaluated all descendant rules as > "Indeterminate", this would not be a problem.) > > Regards, > --Paul > > > -----Original Message----- > > From: Erik Rissanen [ mailto:erik@axiomatics.com ] > > Sent: Monday, April 25, 2011 06:55 > > To: xacml > > Subject: [xacml] The Indeterminate flavors question > > > > All, > > > > Here are some examples which illustrate the points I was > trying to make > > during the TC meeting last week. > > > > The first example intends to show why it is necessary to > evaluate the > > children in order to determine the flavor of Indeterminate from a > > target. > > > > Consider the following policy: > > > > Policy: > > target: resource-id = printer > > subject-id = alice > > Rule[Effect=Permit] > > > > Assume we have the following request: > > > > Subject: > > subject-id = alice > > Resource: > > resource-id = printer > > > > For this request this policy would say Permit. > > > > Now consider this policy: > > > > Policy: > > target: resource-id = bank-account > > subject-risk-level = HIGH > > Rule[Effect=Deny] > > > > This policy would say NotApplicable for the same request as above. > > > > Now, assume that we collect the two policies in a policy set: > > > > PolicySet > > Target: subject-location[MustBePresent='true'] = office > > Policy: > > target: resource-id = printer > > subject-id = alice > > Rule[Effect=Permit] > > Policy: > > target: resource-id = bank-account > > subject-risk-level = HIGH > > Rule[Effect=Deny] > > > > Now, let's evaluate this policy against the example request > from above. > > > > The target of the policy set will be Indeterminate because the > > subject-location attribute is missing. Now, which flavor of > > Indeterminate should it be? It should be Indeterminate{P} > since only a > > permit could have been produced if the target would not have failed. > > And > > we know that only if we evaluate the children. Note that simply > > scanning > > the policy tree for effects would incorrectly conclude that > the policy > > might have evaluated to a Deny for this request. > > > > > > Now, there was another issue which was discussed at the > meeting, namely > > that Paul had an idea that instead of having to actually > evaluate all > > the children, one could think of the policy is being transformed. I > > need > > to bring up another example to illustrate that. (I did not > want to mix > > two issues in the same example policy.) > > > > Consider this policy set: > > > > PolicySet > > Target: subject-location[MustBePresent='true'] = office > > Policy[CombAlg='deny-unless-permit']: > > Target[empty] > > Rule[Effect=Permit] > > target: resource-id = printer > > subject-id = alice > > Rule[Effect=Deny] > > target: resource-id = bank-account > > subject-risk-level = HIGH > > > > > > Again, let's evaluate the policy set with the example request from > > above. The policy set target is indeterminate, so the policy set is > > Indeterminate as a whole. If we would evaluate the children to > > determine > > the flavor of Indeterminate, we would get Indeterminate{P}, > like above > > because the rule about bank accounts does not apply. > > > > Now, Paul thought one could rewrite this policy set by adding the > > expression from the policy set target in each leaf rule as > a condition. > > However, I pointed out that it won't give the same result because of > > the > > combining algorithms. In this case, the rewritten policy would be: > > > > PolicySet > > Target[empty] > > Policy[CombAlg='deny-unless-permit']: > > Target[empty] > > Rule[Effect=Permit] > > target: resource-id = printer > > subject-id = alice > > condition: subject-location[MustBePresent='true'] = office > > Rule[Effect=Deny] > > target: resource-id = bank-account > > subject-risk-level = HIGH > > condition: subject-location[MustBePresent='true'] = office > > > > Íf we evaluate this policy set against the example request, we get > > Indeterminate in both rules because of the missing > attribute in their > > conditions. However, the 'deny-unless-permit' algorithm is going to > > change that to a Deny for the policy which contains the rules, so > > overall we get Deny, which is different from the policy set > before we > > transformed. > > > > The question Paul brought up during the meeting was whether this was > > intended. Clearly that is what the spec says happens since the > > evaluation tables allow a combining algorithm to make a > decision among > > several conflicting decisions. I guess what Paul is > thinking about is > > that there should be some kind of "linearity" requirement, by which > > certain properties of the policy are immutable under > certain types of > > transformations in the policy. > > > > However, there are currently no general requirements on the > algorithms > > which would guarantee that certain decisions are not overridden. I > > don't > > think there should be either. > > > > Best regards, > > Erik > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php