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 Rich and Anne (and everyone else),

As far as I can tell all of this is already fully covered by the current
text in section 7, Functional requirements (XACML 2.0). This section
goes through every part of XACML and specifies how each part is
evaluated, including when they return Indeterminate. I would not like to
change the current text as I think it is clear and correct. (Let me know
if there is a particular section in which I didn't notice an error or if
something is missing.)

Where the text could be improved is in the specification of the status
codes. Currently they are specified in a separate section 7.15, which,
as Rich pointed out was worded in a confusing way, so it seemed it tried
to define the conditions under which Indeterminate occurs in an
incorrect manner.

It would be better to specify status codes at each point in section 7
where an Indeterminate result is defined.

Another issue is that if a policy contains multiple errors, there might
be a conflict in the specification on which particular status code must
be returned. I think resolving this is best left to be implementation
specific, since a typical implementation would stop at the first error
it notices in any case. But it might be a good idea to say this in the
spec as well.

Regards,
Erik

Rich Levinson wrote:
> 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]