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] Specification of extended indeterminate in combiningalgorithms is incomplete

Hi Matthew,

For convenience to all, the extended indeterminate is defined in section C.1 of the spec. http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.html#_Toc265751171 (link to the current CS version).

You are right that it's underspecified now that I read it again. Specifically, as you say, the following is not well defined:

- How shall an "Indeterminate" returned form a "normal" algorithm be treated by an "extended" algorithm?

The intent has been that a "legacy" indeterminate corresponds to a Indeterminate{DP} since the legacy algorithms do not track the different cases. It should have been written out.

Regarding the reverse question, what a legacy algorithm should do with an extended value, then the legacy algorithm would ignore the additional indeterminate value, and treat it just as a plain Indeterminate. I think that is what the spec implies as it is, but it should have been explicitly spelled out.

Regarding your question about the target, I agree that it's underspecified and there are also a couple of sensible things that could be done. I guess the most sensible thing would be that depending on what the combination algorithm returns (Permit, deny, a variant of indeterminate), you would return the appropriate extended value for the policy/policy set as a whole if there is an Indeterminate in the target.

Not sure how to fix this in practice as errata. Hal?

Best regards,

On 2011-03-11 21:07, Wood, Matthew D wrote:
8DD2590731AB5D4C9DBF71A877482A90017C2C8834@orsmsx509.amr.corp.intel.com" type="cite">

The 10/8/2010 committee specification (using urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 namespace) appears to be incomplete with respect to extended indeterminate states in the combining algorithms. The new combining algorithms are defined entirely in terms of extended indeterminate, but there are cases where extended indeterminate values are not available:

-          Algorithms present since the XACML 1.x, whether or not they are marked for deprecation, are only specified in terms of indeterminate

-          Indeterminate results from evaluating a policy target

There are no indications about how to handle unextended indeterminate values in the new algorithms or how an extended indeterminate should be propagated through pre-3.0 algorithms.


For the first-applicable combining algorithms, it seems reasonable to propagate the variant of indeterminate as the result of the algorithm on lines 5646 and 5685 for the rule and policy combining algorithms, respectively. The others are unclear to me, though specification about how to handle unextendend indeterminate results in the new algorithms would also solve the problem in a seemingly simpler manner.


This issue makes it unclear about what should be proper conforming behavior.


Another minor omission is lack of explicit indication that obligations and advice should be handled according to section 7.16 after the pseudo-code for the first-applicable rule combining algorithm, as appears for all other rule and policy combining algorithms.


Matthew Wood

Sr. Software Engineer

SSG Software Pathfinding Initiative


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