OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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