[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)
Thanks for your feedback. If that helps, there are several statements in the spec that strongly suggest that a Policy is said "Applicable" to the request if and only if its Target matches. Here's a few quotes: 1) Section 2.9: "PDPs are expected to confirm, by examining the policy's <Target> element that the policy is applicable to the decision request that it is processing." 2) Section 4.1.1: [a13] "In this simple example, the target section says the policy is applicable to any decision request." Line a13 corresponds to the Policy's Target. (Note that there is also a Rule in this Policy if you look at the example, but it is not mentioned in this comment.) 3) Section C.9 (Only-one-applicable algorithm): "only one policy is considered applicable by evaluation of its target [...]". Note that the pseudo-code of this algorithm refers to a function "isApplicable(policy)". This function is not mentioned as is in the text (this should be fixed), but we can guess from the previous text that it means to evaluate the policy's Target. We also understand that the function isApplicable() takes a Policy or PolicySet argument and returns an "ApplicableResult" which appears to be an enum of 3 constants: Applicable, NotApplicable and Indeterminate. Regards, Cyril 2016-05-13 0:44 GMT+02:00 Steven Legg <steven.legg@viewds.com>: > 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 >> > > > -- > This publicly archived list offers a means to provide input to the > OASIS eXtensible Access Control Markup Language (XACML) TC. > > In order to verify user consent to the Feedback License terms and > to minimize spam in the list archive, subscription is required > before posting. > > Subscribe: xacml-comment-subscribe@lists.oasis-open.org > Unsubscribe: xacml-comment-unsubscribe@lists.oasis-open.org > List help: xacml-comment-help@lists.oasis-open.org > List archive: http://lists.oasis-open.org/archives/xacml-comment/ > Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml > Join OASIS: http://www.oasis-open.org/join/ >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]