[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-comment] Possible typos in XACML 3.0 Core specification (SubjectCategory, PolicyIdentifierList)
On 13/05/2016 5:24 AM, Hal Lockhart wrote:
I will offer my opinions, but I defer in advance to Erik. #1. I think you are right. We missed removing SubjectCategory from this section. #2. You have a point. The phrase “the <Condition>” is not correct, since a policy may have more than one rule and hence more than one <Condition> element. I think the original intent would be better met by saying that for a PolicySet the Target must match and for a Policy the Target must match and at least one of the Conditions in the Rules must evaluate to true.
Note that each rule may also have a target. Hal is the authority on what was the original intent, but I ended up implementing something different due to the lack of clarity. My implementation includes a policy set or policy in the PolicyIdentifierList if the overall result of evaluating the policy set or policy is anything other than NotApplicable (which includes policies and policy sets that evaluate to Indeterminate). The idea being to include everything that could have conceivably contributed to the final decision, which seemed a likely requirement. Notwithstanding the deny-unless-permit and permit-unless-deny combining algorithms, a policy set where the target matches but no component policy or policy set is applicable is not included by analogy to a policy where the target matches but no component rule has a matching target and true condition. A policy that has the deny-unless-permit or permit-unless-deny combining algorithm can produce a result that contributes to the final decision even though none of the component rules has a matching target and true condition. In principle, such a policy should be included. Requiring only that the target matches will achieve that, but so will requiring the policy to evaluate to something other than NotApplicable, which has the advantage of excluding more of the non-contributing policies and policy sets. Regards, Steven
Your suggestion would include policies in which the Target matched, but there were no applicable Rules, which doesn’t quite correspond to my notion of an Applicable Policy. In any event it seems we will need to create and process an errata document. Hal *From:*Cyril DANGERVILLE [mailto:cyril.dangerville@thalesgroup.com] *Sent:* Monday, May 09, 2016 8:13 PM *To:* xacml-comment@lists.oasis-open.org *Cc:* cyril.dangerville@thalesgroup.com *Subject:* [xacml-comment] Possible typos in XACML 3.0 Core specification (SubjectCategory, PolicyIdentifierList) Hello, I just want to report two possible issues in the text of the XACML 3.0 Core specification. I suspect this may have been raised before but could not find any track of it, so I just want to make sure. 1) The mention of 'SubjectCategory' attribute in section 8.1: http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html#_Toc325047202 This attribute does not exist anymore in XACML 3.0 model, so I assume it should be removed from the list of extensible XML attribute types. 2) The definition of an applicable policy to be returned in <PolicyIdentifierList>, section 5.48: http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html#_Toc325047153 It says: "all policies where both the <Target> matched and the <Condition> evaluated to true...". Since <Condition> is only in a <Rule>, shouldn't the text say only this instead "all policies where the <Target> matched" (period) ? Thanks for any clarification if I'm wrong. Regards, Cyril -- Cyril Dangerville, CISSP Thales
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]