I like Steven's concept of the requirement:
" The idea being to include everything that could have conceivably contributed to the final
decision, which seemed a likely requirement. "
The case I think of is where a "break the glass" policy is invoked that over-rides the "normal" policy. I think any ex-post review of the transaction would want to see that there was a "normal" policy that was considered, but over-ridden.
This is how I was thinking of the issue when I raised the idea of a "must-understand" or "must-consider" (any "mandatory" Resource Attributes) profile. You'd want to collect all Policies that referred to any "mandatory" resource attribute, regardless of whether the Policy actually determined the finally decision outcome.
Martin
On Thu, May 12, 2016 at 6:44 PM, Steven Legg <> wrote:
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:]
*Sent:* Monday, May 09, 2016 8:13 PM
*To:*
*Cc:*
*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:
Unsubscribe:
List help:
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/
--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile
