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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] New Issue#83: CORE ERRATA: error in 7.15.3 Missing attributes


Hi Anne,

Just looked this over and I think it is exactly what we need. In particular,
when we make statements, such as the one we are wrestling with in
section 7.15.3, then we can refer to the appropriate level of this structure
you have proposed, which will remove all the ambiguities.

One thing I noticed, that may be covered if I understand how to read it,
the 3 "Target", "Target All", "Target Any" statements should address what
I had been trying to say about the "may" being introduced when the
"Target Any" was encountered at the top level elements Subjects,
Resources, etc.

Also, in this regard, the top level Target children, I think are a 
"Target All",
at least as far as the children that are included: Subjects, etc.

Bottom line is I think if people can see this hierarchy of elements and the
way the return values are passed, it will help in the understanding of how
the policies actually work.

    Thanks,
    Rich


Anne Anderson - Sun Microsystems wrote:
> Rich and Erik (and others),
>
> Here is a first pass at a formal description of the situations under 
> which a <Decision> element will have the value "Indeterminate".  I may 
> have left out a situation or a level of the All/Any/All in a Target. 
> The Section numbers are from the XACML 2.0 specification, not 3.0.
>
> The Decision element resulting from an evaluation of a given Request 
> Context MUST have the value "Indeterminate" only if the 
> PolicySetCombiningAlg or PolicyCombiningAlg that defines the PDP 
> (7.13) evaluates to "Indeterminate".  The situations in which a 
> PolicySetCombiningAlg or PolicyCombiningAlg evaluates to 
> "Indeterminate" are part of the specification of the algorithm.  
> Standard XACML PolicySetCombiningAlg and PolicyCombiningAlg algorithms 
> are specified in Appendix C of the XACML core specification.
>
> The following sub-evaluations MAY be required as part of evaluation of 
> the PDP's PolicySetCombiningAlg or PolicyCombiningAlg:
>
> - A PolicySet element SHALL evaluate to "Indeterminate" only if it 
> contains an optional element type or function that the PDP does not 
> support (7.15.1), or if the PolicySet contains invalid syntax 
> (7.15.2), or if the PolicySet contains invalid static data-types 
> (7.15.2), or if its PolicyCombiningAlg evaluates to "Indeterminate".  
> The situations in which a PolicyCombiningAlg evaluates to 
> "Indeterminate" are part of the specification of the algorithm.  
> Standard XACML PolicyCombiningAlg algorithms are specified in Appendix 
> C of the XACML core specification.
>
> - A Policy element SHALL evaluate to "Indeterminate" only if it 
> contains an optional element type or function that the PDP does not 
> support (7.15.1), or if the Policy contains invalid syntax (7.15.2), 
> or if the Policy contains invalid static data-types (7.15.2), or if 
> its RuleCombiningAlg evaluates to "Indeterminate".  The situations in 
> which a RuleCombiningAlg evaluates to "Indeterminate" are part of the 
> specification of the algorithm.  Standard XACML RuleCombiningAlg 
> algorithms are specified in Appendix C of the XACML core specification.
>
> - A PolicySetIdReference element SHALL evaluate to "Indeterminate" 
> only if no PolicySet satisfying the requirements of the 
> PolicySetIdReference is available OR if, when the referenced PolicySet 
> is evaluated, the PolicySet evaluates to "Indeterminate".
>
> - A PolicyIdReference element SHALL evaluate to "Indeterminate" only 
> if no Policy satisfying the requirements of the PolicyIdReference is 
> available OR if, when the referenced Policy is evaluated, the Policy 
> evaluates to "Indeterminate".
>
> - A Rule element SHALL evaluate to "Indeterminate" only if its 
> <Target> element evaluates to "Indeterminate" OR if ( its <Condition> 
> is evaluated AND its <Condition> evaluates to "Indeterminate") .
>
> - A Target element SHALL evaluate to "Indeterminate" only if at least 
> one of its "All" elements evaluates to "Indeterminate".
>
> - A Target All element SHALL evaluate to "Indeterminate" only if at 
> least one of its <Any> MatchId functions that is evaluated returns 
> "Indeterminate".
>
> - A Target Any element SHALL evaluate to "Indeterminate" only if its 
> MatchId function evaluates to "Indeterminate".
>
> - A MatchId function SHALL evaluate to "Indeterminate" only if one of 
> its AttributeSelector or AttributeDesignator arguments evaluates to 
> "Indeterminate".  Note that a MatchId function evaluates to 
> "NotApplicable" rather than to "Indeterminate" if one of its 
> AttributeSelector or AttributeDesignator arguments evaluates to an 
> empty bag of values after considering its "MustBePresent" XML 
> attribute value.
>
> - An AttributeSelector or AttributeDesignator element SHALL evaluate 
> to "Indeterminate" only if its "MustBePresent" XML attribute is "True" 
> AND if it evaluates to an empty bag of values before considering its 
> "MustBePresent" XML attribute value.
>
> - A Condition element SHALL evaluate to "Indeterminate" if any <Apply> 
> function that is evaluated in the Condition returns "Indeterminate".
>
> - An Apply element SHALL evaluate to "Indeterminate" only if its 
> FunctionId function evaluates to "Indeterminate".  The situations in 
> which a FunctionId function evaluates to "Indeterminate" are part of 
> the specification of the function.  Standard XACML functions and the 
> situations in which they will evaluate to "Indeterminate" are 
> specified in Appendix A of the XACML core specification.
>
> Do you think such a formal description would be useful?  Should its 
> components be included in the descriptions of the corresponding 
> elements, or in one place under "Functional requirements", or included 
> in the descriptions of the corresponding elements but referenced one 
> by one in the "Functional requirements"?
>
> Regards,
> Anne


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]